Business as a Service. Software as a Service Billing and Business Models

According to Gartner, Software as a Service (SaaS) is software that is owned, delivered and managed remotely by one or more providers. This means that the application users are not licensed and charged for software availability in extended periods of time, but only billed for the amount they actually use. In most scenarios, the software is either available in the form of web applications or terminal services. In the first case, the entire application is hosted on the provider’s hardware and no client software except for a web browser is needed. In the latter case, the only difference is a requirement for the customers to download a client application, but the core of the system is also hosted by the provider.

Benefits from SaaS

These facts combined mean vast savings for the consumers. The lack of an initial license fee and hardware requirements can reduce the CAPEX significantly. It is also easier to plan the spending and adapt over time. The actual cost of ownership (TCO) depends on how much the applications are used at a particular time and not on future capacity. This flexibility and affordability of the model are especially vital for businesses in today’s economy.

As for the software vendors, the SaaS model offers equally valuable benefits. Initially lower, but recurring revenue streams are much more predictable and provide the ability to plan the budgets more effectively and precisely. Due to the centralized hosting, the software is also much easier to maintain and support. All upgrades are limited to one environment and have instant effect for all users. In addition, direct access to the application logs facilitates bug fixes. Finally, SaaS can help overcome sales difficulties in
a period when businesses reorganize and freeze their IT budgets, so they cannot afford the lack of flexibility and expenses of software based on EULA licensing models.

These advantages are clearly confirmed by good results of the market leaders and optimistic projections of its researchers. Contrary to mostly negative growth forecasts coming from all over the economy, the global SaaS market is expected to grow in 2009 by as much as 30% (Gartner) to 40% (IDC).

Billing and other challenges

The positive aspects of SaaS for software vendors are unquestionable. However, a number of topics need to be addressed before an application can be offered in this model.

The inevitable challenge faced by all Software as a Service providers is setting up the billing process. Whereas traditional IPR or EULA-based sales required simple license invoicing and handling of usually long-term maintenance contracts, the “pay-per-use” model and proper management of frequently recurring transactions impose a requirement for a rating and billing engine, as well as a set of procedures. This means additional analyses and investments need to be made in order to kick off the provision of SaaS.

The necessary infrastructure is offered by many vendors (e.g. Verax Systems with its OSS/BSS Billing). In order to achieve good results, software businesses are required to develop a profitable and competitive usage billing model. One of the first steps is defining the main billing units and UDRs (Usage Data Records) related with them or software license key limitations. The most commonly used aspects are:

• Number of users and sessions per user
• Number of concurrent sessions
• Number of enabled modules / functionalities
• Number of business artifacts generated by the application (e.g. reports, invoices etc.)
• Number of objects created or stored in the application (e.g. articles, contacts etc.)
• Number of emails sent

Obviously, the rating and billing must cater for the business value of the applications, service maintenance costs (like customer support and SLAs), as well as the hardware required to host it (e.g. CPU and storage capacity). The diversity of the parameters may be a difficulty alone. However, this is where another critical challenge occurs.

It is the scalability required to handle a varying number of customers and users. Obviously, a well-established business can make long-term customer base growth plans and set sales targets in order to adapt the infrastructure on time. However, the recent economic reality has made it increasingly difficult for companies to reach those targets. In addition, some of the services offered to customers have a very seasonal nature (e.g. consumer e-commerce usually booms in the Christmas season). This means businesses need to make upfront spending on hardware capacity which is likely to be redundant for extended periods of time. A related challenge is also the provisioning of the services, which also requires appropriate infrastructural solutions to be in place.

A conclusion from the above is that it is not easy for a specialized application provider to offer their software in the SaaS model on their own. Fortunately, the market is rich in solutions similar in the idea, but oriented on hardware infrastructure. It is usually referred to as Infrastructure (or Platform) as
a Service, and a combination of the services is commonly named Cloud Computing.

“Hardware as a Service”

The Infrastructure as a Service providers reduce most of the CAPEX required from software vendors in order to start offering SaaS. Their huge data centers cater for the flexibility allowing for instant multiplication of the hardware resources as the needs grow. The dynamic scalability and provisioning is achieved with the latest platform virtualization monitoring infrastructure (hypervisors), out of which the most commonly used are Cytrix Xen and VMWare (Information Week Analytics, Sept. 4, 2009). Costs are kept down to the minimum due to built-in load balancing mechanisms.

The dynamic growth of interest in SaaS had turned providing scalability, redundancy and provisioning for its purposes into a core business of many companies. Even though, as the concept is relatively new, the implementations and market offerings differ quite considerably. The most commonly listed three services – Amazon’s EC2, Google’s App Engine and Microsoft’s Azure represent different philosophies, with hardly any platform restrictions and added services in the first case, very restrictive policies for a low price in the second, and single platform with value added services in the last example.

With specializations ranging from virtualized and scalable web hosting and disaster recovery through provision of SaaS and test environments for software vendors to leasing high-performance computing resources for research and industrial simulations, the leaders in the most common appliances include Amazon (EC2), Rackspace and GoGrid.

A majority of the providers impose a minimum service duration, although in most cases it is as low as monthly. The services are usually billed according to utility-based or availability models. The charges are commonly applied for the following parameters:

• Hours of virtual machine availability (e.g. Amazon)
• CPU cycles (e.g. Rackspace, Google)
• RAM-hours (e.g. GoGrid)
• Data transfer
• Storage

Additional services, such as monitoring, load balancing, software license fees etc. are also offered and billed for as part of bundled plans or separately. Some providers offer pre-paid plans and monthly or annual subscriptions, although their practical aspect is a price discount or a fee for the “reservation” of
a machine (either virtual or physical) with additional per-use pricing on top of it.

One of the most frequently raised disadvantages of entrusting the hosting of applications to 3rd party companies is the aspect of data security and uptimes. This is addressed by most providers who offer suitable service level agreements (SLA) with uptime levels exceeding 99%. However, it is the small-print that matters. For example, Amazon’s SLA guarantee of 99.95% is calculated on an annual basis, which means a critical system may be down for a few hours within a week with no obligation from the provider. As another one, GoGrid’s 100% SLA level refers to availability as indicated by the operator’s proprietary monitoring tools.

Service separation model

In this model, the software vendor hosts its applications in a selected Data Center providing platform or infrastructure services. The software is offered and sold to end users directly by the application provider and the data center is not part of the process. The application provider is billed for the infrastructure usage. The application sends usage reports to the provider’s billing engine. The entire billing and invoicing process is also handled by the application provider.

The main advantage of this model for the application provider is that the scalability and provisioning is entirely taken care of by the data center. This means a significant cost reduction, as no hardware needs to be purchased and set up in order to provide the service. The sales is directly between the software vendor and the customers. Both the data center and the application provider offer their core business services only.

Despite offering undoubted advantages, this model is not without flaws from the software vendor’s perspective. The requirement of running dedicated sales & marketing departments has been enough of a struggle for many software engineering businesses. The billing and invoicing on top of that may be too much for some executives to handle in a short timeframe.

Revenue sharing model

This is why an alternative and less conservative model is proposed by Verax Systems. It is based on the assumption that it is easier for a large service provider (i.e. data center) with existing billing infrastructure and procedures in place to integrate additional application usage billing processes into it than setting up two separate engines.

The advantages of this model are clearly evident for both the data centers and the application providers. As the revenue is shared between the two parties, both of them have a common business goal, so there is an obvious synergy effect. Also the total cost of this model seems to be lower, so a more competitive and profitable offer can be directed to the customers.

Application providers without the need to handle billing, invoicing and collection processes can put more focus on what they do best. This should result in lower prices for the service, as well as in development of new features or applications. Many small and rather unheard of software companies can vastly benefit due to the service provider’s footprint and market recognition. It also means a safer business with less investments in expensive infrastructure and processes.

The data centers as service-as-a-whole providers gain an opportunity to increase their market share and recognition. First of all, they can expand their customer base by attracting more application providers due to a convenient business model. In a time of increasing competition among infrastructure providers, more of them aim to find market differentiators. This objective can be met by offering added value – clearly achieved by directly providing applications in the SaaS model. Value Added Services at a low expense combined with additional revenue from commission should provide a quick ROI and increase the company’s footprint.

Verax SaaS provisioning and billing infrastructure

Verax Systems positions itself as an infrastructure enabler for the provisioning and billing of SaaS applications supporting various business models, including the revenue sharing in particular. The Verax OSS/BSS Suite covers important areas of building SaaS infrastructure, including:

• Defining new services (Product Catalogue)
• Provisioning (Provisioning Service)
• Customer self management (Self Care Portal)
• Billing of both infrastructure and application usage (Billing)
• Monitoring of the service infrastructure and measuring SLA compliance (NMS)

What is worth mentioning is that Verax Systems’ applications are not limited to the SaaS platform – all our products are oriented at carrier-grade services for IP-centered, convergent telecommunications.

Defining the services

In order to be able to efficiently handle the billing of any kind of services, they have to be precisely defined. What could be just a one-off exercise for a small business offering a limited number of rarely-changing services is usually not the case. Strong market competition enforces introducing new ways of attracting customers and thus, new services. This means that the configuration of new applications becomes a daily routine. The challenging economy is also a time when acquisitions or mergers become very common, resulting in an increase of the number and complexity of the product packages offered. In order to handle the product and service offerings in an efficient and error-free manner, a sophisticated product catalogue, capable of handing SaaS specifics is required.

The Verax Product Catalogue offers a flexible tool to define the SaaS services and means of their billing, such as:

• Service name
• Activation times
• Eligibility criteria
• Billing criteria:
  • Platform usage, such as storage, CPU cycles, data transfers and others
  • Additional application criteria, resembling more a classic license, such as the number of users, sessions, modules enabled, etc.

The Product Catalogue offers an easy, intuitive interface for not only defining the technical details of the services, but also allowing to categorize them for easier browsing, create service bundles (with mandatory and optional products), provide descriptions and photos for the customers and define multi-currency pricing.

Provisioning the services

Provisioning of individual applications is likely the most complex process of a scalable and flexible SaaS infrastructure. In order to attract customers, the offering must be tailored to the needs to the maximum extent. The resulting wide range of pricing and licensing models needs to be reflected in the provisioning mechanism. An indication of the potential challenges is that the provisioning of various SaaS applications may include the following:

• Instantiating a virtual machine from a template
• Setting platform parameters such as storage, database and others
• Setting DNS names
• Managing HTTPS certificates
• Configuring a default administrative account
• Configuring the application license, e.g. three modules for five concurrent users
• Activating the service and billing notification

Verax Systems has been working on a Provisioning Service solution to meet all the challenges faced by our current and potential customers.

Managing the services

A wide range of applications and a large number of users make for an excellent business aspect, as they directly affect the revenue gained. However, the management of customer service becomes more difficult and expensive as the customer-base grows. It is not just a question of instantiating the particular applications, but also responding to the customers’ changing needs.

The easiest way of reducing the customer service costs and making it more manageable is providing the customers with a front-end, where they can manage the parameters of their services on their own. It not only helps to improve and reduce the call center costs, but also increases customer trust and loyalty.

The Verax Self Care Portal allows this and much more, by providing enhanced possibilities of customer communication (e.g. broadcasting news, events, new products), improving the service with a service rating feature and accelerating the cash flow by presenting outstanding payment information to the customers.

SLA compliance

The provider’s liability and proposed Service Level Agreements are one of the most frequently asked questions when it comes to managed services. Security concerns are the main argument against using SaaS for 30% of decision makers surveyed by Forrester in 2009. This is why it is essential for any SaaS provider to deploy the right tools and procedures to maintain the required level of availability and data security, as well as to demonstrate them to their current and potential customers.

It is not just the hardware infrastructure that matters. In order to avoid dropping below the SLA-declared parameters by reacting to problems before they become critical, the SaaS providers need to have
a proper monitoring system in place.

Verax Systems’ Network Management System is a perfect match to those needs, both for the platform as well as the applications. The Verax NMS provides proven SLA compliance and features full FCAPS (fault, configuration, accounting, performance, security) functionality to help maintain the highest level of availability and provide tools for fault prevention. Due to support of rules-based business logic and pluggable architecture, it can be integrated with any existing platforms and applications.

Integration challenges

SaaS applications are usually built on top of existing infrastructures and services. This means that there may likely already be some systems in place. Be it existing client databases, some forms of billing systems or other environments, Verax Systems can integrate with them via:

• SOA-ready architecture with pluggable services – e.g. it is possible to replace the integrated Verax OSS/BSS database and modules with a custom plug-in connecting to an existing database
• Verax mediation, which can be used to relay the UDRs to and from the existing billing system.

Verax Systems has broad experience as an integrator of applications for telecommunications (including Tier-1 operators) and financial markets.

Growing with the needs

It seems obvious that building a proper SaaS infrastructure is an investment. While some businesses can afford to create it within a short period of time, others may need to prioritize and get going with only the most essential parts in place in the start-up period.

Verax Systems understands this and offers delivery of a perfectly-suited solution over time. The suggested and most common order would be to first deploy the provisioning service, followed by automating the billing process, and finally improving SLAs with the NMS and the customer service with the Self Care Portal at a later stage. However, we are open to any needs and ideas.

Summary

Building a SaaS platform is undoubtedly a complex and demanding task. However, setting up the necessary infrastructure around it in order to provision and bill particular applications is also a challenge. Verax Systems with its OSS/BSS Suite offers a perfect set of applications to address these challenges.

For more information please visit our website www.veraxsystems.com or contact us.

About the Author

(ArticlesBase SC #1493451)

Article Source: SOA Service Oriented Architecture, SOA Web Services, SOA Software as a Service, SaaS. http://www.articlesbase.com/ - Business as a Service. Software as a Service Billing and Business Models

Software as a Service (saas) - Change is Imminent

Software-as-a-Service (SaaS) is receiving a lot of attention in analysts’ briefings and technology trade press articles. In the past year, SaaS has emerged from its pioneering group of start-ups and medium-sized vendors to be embraced, albeit awkwardly, by software giants including Oracle and SAP. Much of the attention SaaS has garnered in recent months has focused on the new business model that on-demand software enables. However, some veteran technologists who’ve adopted SaaS for their own livelihood, and analysts as well, say that the phenomenon might well be the catalyst for a far wider-ranging discussion on software development for the next generation. The highly interactive Web 2.0 model and iterative development have dovetailed to force even the most traditional programmers to at least consider the end of lengthy development cycles. Software as a Service develpment companies are now perfectly positioned to provide all business software applications delivered via the clooud - no software to download, no risk of piracy, and no risk of hard drive failures.

Technology and culture driving business One major technological factor in advancing the new development models might be the rise of service-oriented architecture (SOA) and Web services standards. The ASP model, championed in the late 1990s and early years of this decade, never took off because its one-to-one architecture was inherently difficult to scale. SaaS technology, however, takes advantage of a one-to-many SOA-enabled architecture that can offer customized services to different customers, and even different branches of the same enterprise. One example is a customer relationship management application offered on a SaaS basis by LiveCRM LiveCRM enables companies to drive sales productivity, increase visibility, and expand revenues with an affordable, easy-to-deploy service that delivers success to companies of all sizes. The beauty of a product like LiveCRM lies in its ability to adapt to different business practices and provide a unique customised solution to each without rebuilding the interface each time - This is where SaaS becomes so powerful. Deploying a SaaS application means a major culture change within the organisation. The change comes not just in how things are seen and reported on through aq software product, but also how the product itself is used. Many large organisations (predominantly the older ones) have spent a significant amount on training personnel and getting them used to the current systems and software products used. In my experience, many of these personnel are not as skilled as some of the younger counterparts which presents a very steep learning curve for businesses. However, there is light at the end of the tunnel. SaaS can be deployed in bite sizes; module by module and as people get more used to it, a full scale deployment can be considered. Also, a carefully managed implementation including change management, workshops and solution recipes are also a great way to minimise this learning curve. So a change in technology, in this case, also demands a change in culture. But a change in culture is already happening The technological advancements underpinning the new methodologies are being complemented by a new “ground up” ethos that will force academic program leaders and enterprise strategists to retool their own thinking. In fact, the shift is a generational shift. Just as the young technologists of the late 1980s created both ad hoc and formal transitions of enterprise data from mainframes to PCs and client-server architectures, the next-gen architectures of on-demand software are being pioneered by those who have grown up working with instantly available Web-based applications. From an executive perspective, SaaS is less about how software is going on-demand, and more about how the generation of users who have grown up with the Web as a technology are coming into the workforce. And this crowd expects the tools that allow things they’re used to—collaboration, immediate ubiquitous access, and so on—SaaS will make sure they get what they want. Web 2.0 and socially-oriented computing, as most people think of it, is about Facebook and mashups and things like that. While that’s a big component of the overall discussion, what I try to do is take those concepts and say, ‘How do I take those ideas, which are incubated in the Internet kiddies’ domain, and put that in real business terms—enterprise quality of service, or levels of security, compliance, audit, control and so forth—that are enterprise-worthy or government-worthy, and still keep all the beauty and openness and free-flowing nature of the Web 2.0 world? Uneasy transition Gartner’s Norton says the transition to SaaS-based architectures is still in its early phase. “By 2010, 15 percent of large companies will start projects replacing their ERP backbone with a SaaS offering,” he says. “A little later, Tier 1 consultancies will offer SaaS services, and 30 to 40 percent of vendors offering SaaS service by 2012.” Norton estimates about half of the Web 2.0 projects visible to end users are still developed using noniterative development methods, but he sees that changing. However, Norton says he has seen the promise of some flexible projects run aground just as they might become more useful in a cross-enterprise manner, because corporate executives lose their nerve and fall back on old development methods as projects get larger. “They don’t know what they’ve got, and it’s easier to say, ‘If we put the standard controls in place, we can control this beast.’ They only have the illusion of control.” In all but the most daring organizations, it will take time to realize that the illusion of control might best be modified in favor of a collaborative, nonhierarchical approach. Vandervoort says the next generation of developers is coming out of universities well-informed of these technologies, but are receiving little to no formal training in how to use them in enterprise settings. “The shift that has to occur, both in academic training and in enterprise thinking, is to move away from the idea that IT builds the answer for the user,” he says. He sees Web 2.0 enabling IT to shift its thinking toward enabling users to build their own solutions. In doing that, he says users will find their own answer via the path of least resistance, or POLR. What do you think?

About the Author

Manas is CEO of Genesis Interactive, an Auckland based SaaS vendor and technology innovator.

(ArticlesBase SC #712170)

Article Source: Software as a Service (SaaS), SOA Service Oriented Architecture, SOA Web Services, SOA 2010. http://www.articlesbase.com/ - Software as a Service (saas) - Change is Imminent

What About The Web Services?

RPC is basically a method call interface that many developers understand. The basic unit of these types of services is the WSDL operation. It is not loosely coupled, though, it is used by mapping services directly to specific method calls. THis is not the easiest one to understand, though, and not very reliable.

SOA, or service oriented architecture is where the message is the basic unit of communication, not the operation. It is also called "message oriented" services. Most big software companies and industry analysts use SOA. It uses loose coupling because it focuses on the contract that the WSDL provides and not the implementation details that are underlying.

REST, or representational state transfer is using HTTP by stopping the interface to a set of well known, normal operations. It focuses on interaction with stateful resources instead of messages and operations. It uses WSDL. You can use SOAP with REST or not, it is really up to you.

Most web services that are not REST are often complicated and hard to use. Most SOAP toolkits have made it very easy to define new interface for interaction remotely and also use introspection to get WSDL. It can often be brittle because of this. There are also concerns with the performance because web service uses XML as a message format and HTTP and SOAP are used with sending but XML technologies are becoming better every day.

Any company that wants to succeed uses business and technology to satisfy their customers. It will help the business operate better when they want to use the latest technology, like the internet and mobile. It has really helped new business models become designed. The main business is the e commerce or e business. These businesses do their business solely on the internet.

Because most businesses do their selling on the internet primarily, web services are now very important. Basically, it sets up how the transaction is handled when a customer wants to buy your product. It tells the website how to process the payment and transaction. It is actually hugely important to most businesses because it sets up how easy it will be for the customer to buy your products.

If you have your own company on the internet then you may want to think about getting some advice before you decide which web service to use. You will really want to pick one that is easy for you and the customer but is also very reliable and fast.

Web services are tools that you can use several different ways. The most popular styles are SOA, REST and RPC. They are architectural elements. The type of web service that you choose will make or break your internet company. It will make it easier or harder for your clients to purchase items from you over the internet. It is a good idea for you to understand and know what each type of web service can do before you can really make up your mind.

About the Author

Tampa SEO provides search engine optimization services for small and large businesses. For a free Tampa Search Engine Optimization Audit contact Big U Media today at 813-984-2800.

Topics : Web Services, SOA, Service Oriented Architecture. Source: goarticles.com

SOA Glossary - Web Service

Service Oriented Architecture SOA Glossary - Web Services

A Web service is a body of solution logic that provides a physically decoupled technical contract consisting of a WSDL definition, an XML schema definition, and possibly a WS-Policy definition. This service contract exposes public functions (called operations) and is therefore comparable to a traditional application programming interface (API).

The logic encapsulated by a Web service does not need to be customized or component-based. Legacy application logic, for example, can be exposed via Web service contracts through the use of service adapter products. When custom-developed, Web service logic is typically based on the use of modern component technologies, such as Java and .NET. In this case, the components are further qualified as core service logic.

Source: SOA Service Oriented Architecture Glossary at soaglossary.com

What is Web Services?

Web Service คืออะไร

หากเรามองย้อนกลับไปซักไม่กี่ปีที่ผ่านมาใครจะไปคาดคิดว่าเว็บมันจะเติบโตและได้รับความนิยม สูงมากขนาดนี้ ทุกวันนี้หลายๆ คนคงขาดเว็บไม่ได้ เหตุผลที่เว็บประสบผลสำเหร็จก็คงเป็นเพราะเหตุผลเพียงไม่กี่อย่างคือ ความสะดวก และใช้งานง่าย ในฝั่งผู้ให้บริการ (ผ่านเว็บ) ก็จะมองว่าถ้ามีเว็บเซอร์เวอร์ ก็ขายสินค้าได้ทั่วโลก ในฝั่งผู้ใช้งาน ขอให้คุณเลื่อนเมาส์กับใช้ keyboard เป็น คุณก็ติดต่อ ค้นหา ซื้อของ ได้ทั่วโลก ในมุมมองของ Software เว็บก็ทำหน้าที่อยู่ 3 อย่างคือ GET POST และ ก็ PUT ในเรื่องของ Web Service ก็คือการใช้ Web ที่ไม่เพียงแค่เกี่ยวกับข้อมูลอย่างเดียว แต่หมายถึงการบริการด้วย

คำว่า Service ไม่ได้หมายถึงอะไรที่เด่นชัดอย่าง Promool.com Pantip.com Mfatix.com แต่หมายถึงส่วนประกอบที่คนอื่นๆนำไปใช้ในการทำบริการที่กว้างกว่านี้ด้วย ตัวอย่างเช่น Microsoft Passport ที่ให้บริการตรวจสอบความเป็นตัวตนจริง (Authentication) ผ่านเว็บ ทำให้การบริการข่าวของ Bangkok Post ไม่ต้องตรวจสอบการเข้าสู่ระบบเอง แต่ยกให้ Passport เป็นตัวจัดการแทน หรืออย่าง Dynamic services whitepaper ของ Oracle ก็มีส่วนที่ให้บริการ แปลงค่าเงิน แปลภาษา การส่งของ กระบวนการเคลมสินค้า เป็นต้น ส่วนความหมายอย่างเป็นทางการของ Web Service ก็คงเป็นของ IBM ที่กล่าวว่า

เว็บเซอวิส คือ Web Application ยุคใหม่ ที่ประกอบด้วยส่วนย่อยๆมีความสมบูรณ์ในตัวเอง สามารถติดตั้ง ค้นหา เริ่มทำงานได้ผ่านเว็บ Web Service สามารถทำอะไรก็ได้ตั้งแต่งานง่ายๆ เช่นดึงข้อมูล จนถึงกระบวนการทางธุรกิจที่ซับซ้อน เมื่อ Web Service ตัวใดตัวหนึ่งเริ่มทำงาน Web Service ตัวอื่นก็สามารถรับรู้และเริ่มทำงานได้อีกด้วย

หลายคนอาจจะถามว่าทำไมต้องเป็น Web เพราะเรามี Middle Ware อื่นๆมากมายเช่น RMI Jini CORBA DCOM ฯลฯ แม้ Middle Ware เหล่านี้จะสามารถรองรับได้ แต่ไม่มีตัวใดตัวหนึ่งที่เด่นจริง แต่ในเมื่อ Web มีจุดเด่นในเรื่องของการให้บริการข้อมูลที่สะดวก ใช้งานง่าย จึงกลายเป็นตัวประสาน Middle Ware ต่างๆ เข้าด้วยกันซึ่งจะให้คุยกันเองคงยากยิ่ง Web ทำหน้าที่เป็นตัวกลางให้ Middle Ware เหล่านี้สามารถคุยกันได้ และมีประสิทธิภาพกว่าวิธีการเดิมๆ มาก

หากเรามองจากกรณีของ n-tier application จะพบว่า web service คือกลไกในการเข้าถึงบริการที่แต่ละ Middle Ware ให้บริการ การเข้าถึงจะอาศัย Listener และส่วนประกอบที่ระบุถึงบริการต่างๆ ที่รองรับการทำงาน โดยการทำงานจริงๆ นั้นก็ใช้วิธีการปกติของ Middle Ware นั้นๆ

The SOA implications of Oracle's BEA purchase

SOA News : The SOA implications of Oracle's BEA purchase By Rich Seeley

This fall, leaves will turn bright colors in New England, Americans will elect a new president and what Oracle Corp. plans to do with BEA Systems Inc. after the $8.5 billion acquisition closes may be clearer.

Until then little is certain beyond the "do-the-math" facts that BEA shareholders, led by investor Carl C. Icahn, will make money on the sale and Oracle, led by CEO Larry Ellison, expects to make money from BEA's continuing software licenses and sales.

At a teleconference to announce the deal on Wednesday, Ellison said Oracle expects BEA software sales and license fees to increase Oracle's earnings per share by one to two cents per share in the first 12 months after the deal closes. That apparently assumes that BEA revenues will be robust even if there is a U.S. economic recession.

Dana Gardner, principal analyst of Interarbor Solutions LLC., suggests that recession fears may have played a role in convincing a reluctant BEA board of directors to accept Oracle's offer, which amounted to $19.38 cents per share in cash for shares that closed Tuesday on the NASDAQ stock exchange at $15.58. With the stock markets closing lower almost every day, there may have been a sense that this was going to be as good as it would get perhaps for several years.

"Just fear of a recession has whacked tech stocks, so it would be harder for BEA to hold out for more from any buyer for next year or two," Gardner said. "Second, BEA needs to show strong growth in revenues, especially new licenses, to validate the higher price it was seeking. Next one or two quarters might not work out to prove that in a recessionary or fearful climate."

With no other buyer appearing interested and Oracle offering a cash price significantly higher than the recent share closing in a market spiraling downward, Icahn, who owned 13 percent of BEA shares may not have wanted to risk a prolonged holdout.

"So the recession or just fear of recession made BEA's notions of getting much more than Oracle was proposing less and less likely," Gardner said. "Plus, we can assume that activist investor Carl Icahn also saw the writing on the wall for tougher times and probably put added pressure to sell when an Oracle deal was possible."

Source: For more informaiton on Service Oriented Architecuture SOA news, "The SOA implications of Oracle's BEA purchase" visit http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1294494,00.html

BPM and Web Services

Service Oriented Architecture SOA Articles : BPM and Web Services by Thomas Gomez

Today's IT executives want the best software available. With business process management that means finding solutions that provide key benefits. In addition
to facilitating system integration, these solutions must minimize costs, protect software investments, and increase corporate flexibility--all while generating a quick return on investment (ROI).

Previously, IT executives had an option. They could either create their own processing solutions or buy them as packaged applications. Both approaches were costly. These solutions also had a major downside. Once encoded, they were difficult to change. This encoding prevented businesses from quickly meeting its customers' needs. More importantly, it hindered adaptability to a dynamic increasingly demanding marketplace.

Combining BPM and Web services changes that. This union provides businesses with a powerful set of benefits. It increases efficiency and flexibility, reduces costs, and protects software investments by integrating and recombining with a company's existing systems. In addition, the union provides real-time visibility into processing systems as well as a way to monitor and evaluate key performance indicators-- the prerequisites needed to implement a continuous improvement program.

A Tactical Implementation of SOA

The foundation for BPM and Web services is a service-oriented architecture (SOA). Web services is a tactical implementation of SOA, which bridges the gap between businesses and IT through a set of business-aligned services using a unique set of design principles, patterns, and techniques.

SOA involves the dynamic discovery, organization, and description of services, which enables companies to select, bind, and invoke a service over the Internet. SOA differs from service-based architectures, like RosettaNet or OBI (Open Buying on the Internet), which focus on formats and protocols. A service-based architecture is part of an SOA.

Key SOA Components

The major components of an SOA are a service directory, a service provider, and a service requestor. The service directory contains information about all the available services. A service provider publishes a service by adding the appropriate entries to the directory, which a service requestor uses to find the appropriate service.

When a service requestor finds a match, it binds to the provider using information maintained by the directory. The binding information contains the protocol specifications that requestors must use as well as the structure of the request messages and the resulting responses. The two companies then form a "business partnership."

When the service requestor no longer needs the provider's services, it dissolves the partnership. It then forms new requirements and puts them into a query called a locator, which is run against the service directory. The locator returns a list of possible providers, from which the service requestor chooses a new business partner, and the whole process starts again.

When the business partners bind, they create a "virtual" application. The partners temporarily combine their services to meet an immediate need and capture a business process. Once captured, the business process is automated using workflow management technology. The applications are then integrated and work is routed to the appropriate departments.

Considerations in Deploying an SOA

Businesses who want to deploy an SOA face three considerations. First, current object-oriented analysis and design (OOAD) methods don't address the primary elements of an SOA: services, flows, and components for realizing services. Companies must develop or acquire the techniques and processes required to identity, specify, and realize the individual services. The also need the enterprise-wide components to ensure the quality of services.

Second, a shift in corporate mindset must occur. Companies must shift their thinking from strictly a production-oriented goal to the key SOA objective: enhanced customer service. Whether its Web services or another implementation, SOA is designed to provide customers with services that meet their unique requirements. That's a major leap for some companies but making the transition is a must obtain SOA's benefits.

Third, applications created for one business or product line can now be used in a supply chain and be exposed to business partners who might compose, combine, and include them into new applications, creating what some analysts are calling the service ecosystem or a service value-net. Executive must accept this possibility.

Companies need to address these considerations before deploying an SOA. Unless they do, they won't reap the benefits of an SOA. Nor will they have the adaptability need to compete successfully in the days ahead.

The Role of BPM Technology

BPM technology provides the tools and infrastructure to define, simulate, and analyze this business process model. It does so in such a way that the process is manageable from a business perspective using business solution management tools. A dashboard, for example, provides information about execution status and progress in various levels of detail.

Business analysts then compare readouts to key performance indicators to evaluate the processes performance. If a process is not meeting its objectives, executives change the process. It's here where methodologies, like Six Sigma, are implemented as part of a continuous improvement program. The goal, of course, is to provide customers with the highest quality services.

Conclusion

Combining BPM technology and Web services represents more than just an advanced approach to automating business processes. It takes it to a whole new level. With support from SOA, the combination provides benefits cost-conscious enterprises want from their IT solutions--increased flexibility, ease of integration, protection of existing investments, and a quick ROI.

Peter Peterka is President of Lean Six Sigma us. For additional information on Six Sigma Green Belt or other Six Sigma Consulting contact Peter Peterka.

Source: http://www.goarticles.com/cgi-bin/showa.cgi?C=161941

Web Services definition

Service Oriented Architecture SOA - Web Services definition

The term "Web Services" can be confusing. It is, unfortunately, often used in many different ways. Compounding this confusion is term "services" that has a different meaning than the term "Web Services." On this site, the term Web Services refers to the technologies that allow for making connections. Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered. The combination of services - internal and external to an organization - make up a service-oriented architecture.

Source: http://www.service-architecture.com/web-services/articles/web_services_definition.html

BPM and Web Services

SOA Service Oriented Architecture : BPM and Web Services by Thomas Gomez

Today's IT executives want the best software available. With business process management that means finding solutions that provide key benefits. In addition
to facilitating system integration, these solutions must minimize costs, protect software investments, and increase corporate flexibility--all while generating a quick return on investment (ROI).

Previously, IT executives had an option. They could either create their own processing solutions or buy them as packaged applications. Both approaches were costly. These solutions also had a major downside. Once encoded, they were difficult to change. This encoding prevented businesses from quickly meeting its customers' needs. More importantly, it hindered adaptability to a dynamic increasingly demanding marketplace.

Combining BPM and Web services changes that. This union provides businesses with a powerful set of benefits. It increases efficiency and flexibility, reduces costs, and protects software investments by integrating and recombining with a company's existing systems. In addition, the union provides real-time visibility into processing systems as well as a way to monitor and evaluate key performance indicators-- the prerequisites needed to implement a continuous improvement program.

A Tactical Implementation of SOA

The foundation for BPM and Web services is a service-oriented architecture (SOA). Web services is a tactical implementation of SOA, which bridges the gap between businesses and IT through a set of business-aligned services using a unique set of design principles, patterns, and techniques.

SOA involves the dynamic discovery, organization, and description of services, which enables companies to select, bind, and invoke a service over the Internet. SOA differs from service-based architectures, like RosettaNet or OBI (Open Buying on the Internet), which focus on formats and protocols. A service-based architecture is part of an SOA.

Key SOA Components

The major components of an SOA are a service directory, a service provider, and a service requestor. The service directory contains information about all the available services. A service provider publishes a service by adding the appropriate entries to the directory, which a service requestor uses to find the appropriate service.

When a service requestor finds a match, it binds to the provider using information maintained by the directory. The binding information contains the protocol specifications that requestors must use as well as the structure of the request messages and the resulting responses. The two companies then form a "business partnership."

When the service requestor no longer needs the provider's services, it dissolves the partnership. It then forms new requirements and puts them into a query called a locator, which is run against the service directory. The locator returns a list of possible providers, from which the service requestor chooses a new business partner, and the whole process starts again.

When the business partners bind, they create a "virtual" application. The partners temporarily combine their services to meet an immediate need and capture a business process. Once captured, the business process is automated using workflow management technology. The applications are then integrated and work is routed to the appropriate departments.

Considerations in Deploying an SOA

Businesses who want to deploy an SOA face three considerations. First, current object-oriented analysis and design (OOAD) methods don't address the primary elements of an SOA: services, flows, and components for realizing services. Companies must develop or acquire the techniques and processes required to identity, specify, and realize the individual services. The also need the enterprise-wide components to ensure the quality of services.

Second, a shift in corporate mindset must occur. Companies must shift their thinking from strictly a production-oriented goal to the key SOA objective: enhanced customer service. Whether its Web services or another implementation, SOA is designed to provide customers with services that meet their unique requirements. That's a major leap for some companies but making the transition is a must obtain SOA's benefits.

Third, applications created for one business or product line can now be used in a supply chain and be exposed to business partners who might compose, combine, and include them into new applications, creating what some analysts are calling the service ecosystem or a service value-net. Executive must accept this possibility.

Companies need to address these considerations before deploying an SOA. Unless they do, they won't reap the benefits of an SOA. Nor will they have the adaptability need to compete successfully in the days ahead.

The Role of BPM Technology

BPM technology provides the tools and infrastructure to define, simulate, and analyze this business process model. It does so in such a way that the process is manageable from a business perspective using business solution management tools. A dashboard, for example, provides information about execution status and progress in various levels of detail.

Business analysts then compare readouts to key performance indicators to evaluate the processes performance. If a process is not meeting its objectives, executives change the process. It's here where methodologies, like Six Sigma, are implemented as part of a continuous improvement program. The goal, of course, is to provide customers with the highest quality services.

Conclusion

Combining BPM technology and Web services represents more than just an advanced approach to automating business processes. It takes it to a whole new level. With support from SOA, the combination provides benefits cost-conscious enterprises want from their IT solutions--increased flexibility, ease of integration, protection of existing investments, and a quick ROI.

Peter Peterka is President of Lean Six Sigma us. For additional information on Six Sigma Green Belt or other Six Sigma Consulting contact Peter Peterka.

Source: http://www.goarticles.com/cgi-bin/showa.cgi?C=161941

Service-Oriented Computing in the Real World - Service-Oriented Design

SOA Service Oriented Architecture

Service-Oriented Computing in the Real World - Service-Oriented Design

The service-oriented design process uses a set of predefined service candidates from the service inventory blueprint as a starting point from which they are shaped into actual physical service contracts.

When carrying out service-oriented design, a clear distinction is made between service candidates and services. The former represents a conceptual service that has not been implemented, whereas the latter refers to a physical service.

As shown in the following figure, the traditional (non-standardized) means by which Web service contracts are generated results in services that continue to express the proprietary nature of what they encapsulate. Creating the Web service contract prior to development allows for standards to be applied so that the federated endpoints established by Web services are consistent and aligned.

This "contract first" approach lies at the heart of service-oriented design and has inspired separate design processes for services based on different service models. For more information, visit www.SOAMethodology.com.

Service-Oriented Computing in the Real World - Service-Oriented Analysis

SOA Service Oriented Architecture

Service-Oriented Computing in the Real World - Service-Oriented Analysis

To effectively deliver standardized services in support of building a service inventory, it is recommended that organizations adopt a methodology specific to SOA and consisting of structured analysis and design processes.

Within SOA projects, these processes are centered around the accurate expression of business logic through technology, which requires that business analysts play a more active role in defining the conceptual design of solution logic. This guarantees a higher degree of alignment between the documented business models and their implementation as services. Agnostic business services especially benefit from hands-on involvement of business subject matter experts, as the improved accuracy of their business representation increases their overall longevity once deployed.

Service-oriented analysis establishes a formal analysis process completed jointly by business analysts and technology architects. Service modeling, a sub-process of service-oriented analysis, produces conceptual service definitions called service candidates. Iterations through the service-oriented analysis and service modeling processes result in the gradual creation of a service inventory blueprint.

While the collaborative relationship between business analysts and architects depicted at the lower half of the above figure may not be unique to an SOA project, the nature and scope of the analysis process is.

For an overview of the step-by-step service-oriented analysis and service modeling processes, visit www.SOAMethodology.com.

Service-Oriented Computing in the Real World - Service Inventory Blueprints

SOA Service Oriented Architecture

Service-Oriented Computing in the Real World - Service Inventory Blueprints

An ultimate goal of an SOA transition effort is to produce a collection of standardized services that comprise a service inventory. The inventory can be structured into layers according to the service models used, but it is the application of the service-orientation paradigm to all services that positions them as valuable IT assets in full alignment with the strategic goals associated with the SOA project.

However, before any services are actually built, it is desirable to establish a conceptual blueprint of all the planned services for a given inventory. This perspective is documented in the service inventory blueprint.

There are several common business and data models that, if they exist within an organization, can provide valuable input for this specification. Examples include business entity models, logical data models, canonical data and message models, ontologies, and other information architecture models.

A service inventory blueprint is also known as a service enterprise model or a service inventory model.

For information about analysis processes associated with service inventory blueprints, visit www.SOAMethodology.com.

Service-Oriented Computing in the Real World - Service Models and Service Layers

SOA Service Oriented Architecture

Service-Oriented Computing in the Real World - Service Models and Service Layers

Regardless of how services are implemented, they are commonly classified into one of the following service models:

- Entity Services
- Task Services (and Orchestrated Task Services)
- Utility Services

Service models help establish functional contexts and a functional boundaries services by providing generic, predefined types that are common to just about any IT enterprise.

Once established, service models can create conceptual service layers (logical groups) that can ease subsequent ownership assignment and overall service governance. Service layers also provide a unique perspective of the services within a given inventory, as most service compositions span multiple service layers.

Service-Oriented Computing in the Real World - About Web Services (Part II)

SOA Service Oriented Architecture

Service-Oriented Computing in the Real World - About Web Services (Part II)

A typical Web service is comprised of the following: - A physically decoupled technical service contract consisting of a WSDL definition, an XML schema definition, and possibly a WS-Policy definition. This service contract exposes public functions (called operations) and is therefore comparable to a traditional application programming interface (API).

- A body of programming logic. This logic may be custom-developed for the Web service, or it may exist as legacy logic that is being wrapped by a Web service in order for its functionality to be made available via Web services communication standards. In the case that logic is custom-developed, it generally is created as components and is referred to as the core service logic (or business logic).

- Message processing logic that exists as a combination of parsers, processors, and service agents. Much of this logic is provided by the runtime environment, but it can also be customized. The programs that carry out message-related processing are primarily event-driven and therefore can intercept a message subsequent to transmission or prior to receipt. It is common for multiple message processing programs to be invoked with every message exchange.

A Web service can be associated with temporary roles, depending on its utilization at runtime. For example, it acts as a service provider when it receives and responds to request messages, but can also assume the role of service consumer when it is required to issue request messages to other Web services.

When Web services are positioned within service compositions, it is common for them to transition through service provider and service consumer roles. Note also that regular programs, components, and legacy systems can also act as service consumers as long as they are able to communicate using Web services standards.

Service-Oriented Computing in the Real World - About Web Services (Part I)

SOA Service Oriented Architecture

Service-Oriented Computing in the Real World - About Web Services (Part I)

The Web services platform is defined through a number of industry standards that are supported throughout the vendor community. This platform can be partitioned into two clearly identifiable generations, each associated with a collection of standards and specifications:

First-Generation Web Services Platform

The original Web services technology platform is comprised of the following core open technologies and specifications:

- Web Services Description Language (WSDL)
- XML Schema Definition Language (XSD)
- SOAP (formerly the Simple Object Access Protocol)
- UDDI (Universal Description, Discovery, and Integration)
- WS-I Basic Profile

These specifications have been around for some time and have been adopted across the IT industry. However, the platform they collectively represent seriously lacks several of the quality of service features required to deliver mission critical, enterprise-level production functionality.

Second-Generation Web Services Platform (WS-* extensions)

Some of the greatest quality of service-related gaps in the first-generation platform lie in the areas of message-level security, cross-service transactions, and reliable messaging. These, along with many other extensions, are being provided by the second-generation Web services platform.

Consisting of numerous specifications that build upon the fundamental first-generation messaging framework, this set of Web services technologies (generally labeled as "WS-* extensions") provides a rich feature-set far more complex both in technology and in design.

Some of the notable WS-* specifications include:

- WS-Security (and WS-SX)
- WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity (and WS-TX)
- WS-ReliableMessaging (and WS-RX)
- WS-Policy
- WS-Addressing

For an introduction to first and second-generation Web services technologies, read the short tutorials located at www.ws-standards.com. To view the actual specifications, visit www.soaspecs.com.

Service-Oriented Computing in the Real World - Services as Web Services

SOA Service Oriented Architecture

Service-Oriented Computing in the Real World - Services as Web Services

It is very important to view and position SOA as an architectural model that is agnostic to any one technology platform. By doing so, an enterprise is given the freedom to continually pursue the strategic goals associated with service-oriented computing by leveraging future technology advancements. In the current marketplace, the technology platform most associated with the realization of SOA is Web services.

The popularity of Web services preceded that of service-oriented computing. As a result, their initial use was primarily within traditional distributed solutions wherein they were most commonly used to facilitate point-to-point integration channels. As the maturity and adoption of Web services standards increased, so did the scope of their utilization.

With service-oriented computing comes a distinct architectural model that has been positioned by the vendor community as one that can fully leverage the open interoperability potential of Web services, especially when individual services are consistently shaped by service-orientation. For example, when exposing reusable logic as Web services, the reuse potential is significantly increased. Because service logic can now be accessed via a vendor-neutral communications framework, it becomes available to a wider range of service consumer programs.

Additionally, the fact that Web services provide a communications framework based on physically decoupled service contracts allows a service contract to be fully standardized independently from its implementation. This facilitates a potentially high level of service abstraction while providing the opportunity to fully decouple the service from any proprietary implementation details. As explored at www.soaprinciples.com, all of these characteristics are desirable when pursuing key principles, such as Standardized Service Contracts, Service Reusability, Service Loose Coupling, Service Abstraction, and Service Composability.

WSDL - Web Services Description Language

WSDL - Web Services Description Language

WSDL (Web Services Description Language) เป็นภาษาที่ใช้อธิบายคุณลักษณะการใช้บริการของ Web Services และวิธีการติดต่อกับ Web Services ความต้องการของนิยามนี้เกี่ยวเนื่องกับความต้องการของ distributed system ที่จะกำหนด Interface Definition Language(IDL) โดยใช้ภาษา XML, WSDL เกิดจากการรวมแนวคิดของ NASSL (The Network Accessible Service Specification Language), WDS (Well-Defined Services) ของบริษัทไอบีเอ็ม, SDL (The Service Description Language) และ SCL (the SOAP Contract Language) ของบริษัทไมโครซอฟท์ ปัจจุบัน WSDL เป็นภาษา ที่อยู่ในการดูแลของ W3C (World Wide Web Consortium) ซึ่งยังไม่เป็นมาตรฐานที่สมบูรณ์ เวอร์ชันที่ใช้งานอยู่ใน ปัจจุบันคือ WSDL 1.1

Web Services

Web Services

Web Services คือ application หรือ program ที่ทำงานอย่างใดอย่างหนึ่ง ในลักษณะให้บริการ โดยจะถูกเรียกใช้งานจาก application อื่นๆ ในรูปแบบ RPC(Remote Procedure Call) ซึ่งการให้บริการจะมีเอกสารที่อธิบายคุณสมบัติของบริการกำกับไว้ โดยภาษาที่ถูกใช้เป็นสื่อในการแลกเปลี่ยนคือ XML ทำให้เราสามารถเรียกใช้ component ใด ๆ ก็ได้ ใน platform ใด ๆ ก็ได้ บน protocol HTTP ซึ่งเป็น protocol สำหรับ World Wide Web อันเป็นช่องทางที่ได้รับการยอมรับทั่วโลกในการติดต่อสื่อสารกันระหว่าง application กับapplication ในปัจจุบัน

Web Service ช่วยให้การเข้าถึงข้อมูลสารสนเทศจากแอพพลิเคชันที่ต่างกันเป็นไปโดยง่าย โดยแอพพลิเคชันนั้นๆ สามารถเขียนด้วย Java และรันอยู่บน Sun Solaris Application Server หรืออาจจะเขียนด้วย C++ และรันอยู่บน Windows NT หรืออาจะเขียนด้วย Perl และรันอยู่บนเครื่อง Linux ซึ่งมาตรฐานของ Web Service ทำให้อินเทอร์เฟซของแอพพลิเคชันเหล่านี้ ถูกอธิบายโดย WSDL และทำให้อยู่ในมาตรฐานของ UDDI หลังจากนั้น จึงสามารถติดต่อสื่อสารถึงกันโดย XML ผ่าน SOAP อินเตอร์เฟซ
Web Service สามารถถูกเรียกใช้ภายในองค์กรเองหรือจากภายนอกองค์กร โดยผ่านไฟร์วอล์ ดังนั้นจึงมีองค์กรใหญ่ๆ มากมาย กำลังพัฒนาระบบที่มีอยู่ของตน ให้เข้ากับ Web Service ซึ่งนับเป็นการลงทุนที่คุ้มค่า เนื่องจาก Web Service สามารถเพิ่มศักยภาพในการทำงานขององค์กร อีกทั้งลดค่าใช้จ่ายในการจัดการทรัพยากรขององค์กรได้อีกทางหนึ่ง

นอกจากนั้น Web Service ยังสามารถใช้ร่วมกับ Web Application โดยส่งผ่านข้อมูลทางอินเตอร์เน็ตได้อีกด้วยซึ่งนับเป็นวิธีที่มีประสิทธิภาพในการติดต่อสื่อสารกับลูกค้าหรือหุ้นส่วน ถึงแม้จะต้องคำนึงถึงระบบรักษาความปลอดภัย และการจัดการรายการของข้อมูลอยู่ก็ตาม แต่ Web Service ได้ใช้มาตรฐานทั่วไปของ internet เรื่องดังกล่าวจึงนับเป็นเรื่องธรรมดาของการสื่อสารผ่านระบบอิเล็กทรอนิกส์

Comparing SOA and Web services

Comparing SOA and Web services

You may have heard service oriented architecture SOA referred to synonymously with Web services. But it's important to realize that service oriented architecture SOA and Web services are not the same. Web services themselves deserve their own, more detailed discussion in a separate paper. In this current paper, let's take a moment to explore why service oriented architecture SOA is not the same thing as Web services.

Remember when the idea of object orientated programming became popular? During that time, C++ was an emerging programming language that happened to have strong support for object-oriented programming. But it would be inaccurate to say that a program written in C++ was object oriented: object orientation is an architectural approach, and C++ happens to be one language by which you could realize this architecture. The same principle holds true for service oriented architecture SOA and Web services. SOA service oriented architecture is the philosophy or approach used in designing the solution. Using Web services is simply a way in which you could realize this architecture. So let's keep in mind that using Web services isn't the only way to build out an SOA service oriented architecture. So, just as it is possible to use C++ as a language and not have an object oriented program, it is also possible to use Web services and not have an SOA.

SOA Standards - Web services standards

SOA Standards - Web services standards

At SOA Software we build the best XML and Web Services Management and Security platform available today. Standards compliance allows SOA Software to focus on delivering the maximum value to our customers.

As a result of the standards, Web services can offer the following benefits to the customer:

• Greatly simplified interoperability between applications and systems, regardless of their technology or location
• Lower cost of application development and deployment due to support of universal standards
• Reduced application maintenance costs due to inherent flexibility

SOA Software is a member of numerous standards bodies and technical committees, including:

• WS-Interoperability (WS-I)
• WS-Security (WS-S)
• Security Services (SAML)
• Web Services Reliable Messaging (WSRM)
• Web Services Distributed Management (WSDM)
• Universal Description, Discovery, and Integration (UDDI)