IBM talks up master data management in WebSphere

IBM talks up master data management in WebSphere by Jitendra

IBM came out with a new version of its WebSphere Product Center middleware Wednesday, emphasizing its enhanced master data management capabilities.

Master data management is the managing of data attributes that best describe a particular product or customer, according to Paraic Sweeney, vice president of product information management with IBM. Determining such attributes can help customers improve the quality of their core data, cutting down on any errors and out-of-date or duplicated information.

WebSphere Product Center (WPC) 5.3 is product information management software that assists users in developing and managing a central repository of master data information. The new version includes a Java API and Web services that can be layered on top of the middleware to facilitate integration with SOA (service-oriented architecture) applications. The software also comes with better search capabilities and improved product location management. Users can use the new features to more quickly find product information specific to a particular region or store, Sweeney said.

Auto parts retailer Carquest. is in the early stages of implementing WPC, currently working with IBM to define, collect, cleanse and configure the master data to be captured in the repository. "We're on a quest to have one version of the truth," said Joe Zucchero, senior vice president and CIO of Carquest International, based in Raleigh, N.C.

Master data about the more than 800,000 auto parts in its 3,400 stores is scattered across Carquest's IT systems, according to Zucchero. The data, sometimes duplicated, is contained in a variety of software including "homegrown software, Access databases and Excel spreadsheets," he said.

Carquest wants to implement service-oriented architecture SOA and it's important for the organization to have a single instance of each piece of data for that deployment, Zucchero added. As part of the move to service-oriented architecture SOA, the company is looking to establish systems of record, with WPC to provide the parts systems of record, he said.

Key master data about a specific auto part includes what year, make, model and engine of car it fits and whether the component can be used in any automobile.

IBM acquired the technology behind WPC in 2004 with the purchase of a business partner Trigo Technologies, which had a product information management offering called Product Center. IBM rebranded the Trigo software as a WebSphere product, bringing out a new version of the offering, version 5.2, last year. Another IBM master data management module, WebSphere Customer Center, is based on technology the vendor acquired last year when it bought data integration software company DWL.

WPC customers are "in the hundreds," according to Sweeney, mostly in North America and Europe, particularly France, Germany, Spain and the U.K. Users include Best Buy, Circuit City, John Lewis and Tesco. IBM has projects under way in Asia, notably in Australia and South Korea, he added.

Visit: Halfvalue.com
(A Unique Shopping Website)

Other useful websites:
Halfvalue.co.uk
Lookbookstores.com

Are You Really Ready for SOA?

Are You Really Ready for service-oriented architecture SOA? By Charlie Feld

June 29, 2007 — CIO — Most major organizations claim to have a service-oriented architecture (SOA) plan. Not to have one would be oldfashioned. However, successful implementation of end-to-end data and business processes integration requires not only a technology architecture but also a parallel business architecture. You simply can't have a modern business model without modern processes, software and infrastructure that are tightly integrated.

But in most enterprises, this integration between IT architecture and the business model remains poorly articulated. I call this the CEO/CIO dialogue gap. This gap exists to some extent because of the relative "newness" of IT as a discipline. Professions like finance and manufacturing have matured over hundreds of years, with principles, structures and a body of knowledge that are well understood by business leaders. However, IT has been part of the commercial landscape for only four decades.

During the last 10 years, some CEOs and CIOs have been able to close the dialogue gap. However, in today's flatter—even upside down—world, competition is much harder and business moves much faster. In such exhilarating and dangerous times, strong leadership really matters. There's no longer any room for miscommunication between the business and IT.

More from Charlie Feld Total Leadership: How to Build a Great Team

Must-Have CIO Skills: Innovation, Business-Savvy

Change Management: Leading Through Technology Changes Critical Alignment
The struggle for business/IT alignment is decades old. But today, the stakes are much higher because technology is becoming fully integrated into every facet of customer, supplier and employee interactions. The challenge for CIOs is multifaceted. First, they must grasp the competitive business context of their enterprise and understand the durable processes that drive the business versus organization structures that are perishable. Then they must be able to build a realistic multiyear modernization plan for the enterprise and establish process, data and investment governance structures with the executive team. Finally, CIOs must be able to articulate the value of the above to their business constituents continuously and with passion.

This is a tall order, but it's critical for the success of a modern enterprise. In the past, we could get away with short-term commitments and much less discipline because we were funding and executing projects that were contained within a business function and limited to a specific technology. But in our current era, most business processes require real-time integration of data and applications. If the business and IT integration model and investment strategy are not well-understood, aligned and managed over multiple years, you could end up with poor business results, dissatisfied customers and out-of-control IT expenses.

Source: http://www.cio.com

Reaping the Big Business Benefits of SOA

Reaping the Big Business Benefits of Service Oriented Architecture SOA By Christopher Koch

July 02, 2007 — CIO — In an exclusive interview with CIO, Andy Baer, CIO of Comcast, talks with Christopher Koch about maximizing the benefits of service-oriented architecture (SOA), including reusing assets and cutting time to market. His expertise stems from developing the internal IT strategy that aligns technology to meet overall business needs and objectives, including oversight of the company's customer care, billing and ordering systems; data centers; desktops; internal telephony; and other corporate systems. He also oversees the integration of the IT organizations in former Time Warner and Adelphia cable systems recently acquired by Comcast.

Christopher Koch, CIO: What do you see as the primary business reason for doing an SOA?

Andy Baer: What you're really getting out of service-oriented architecture SOA are a couple of really big business benefits. You're getting reuse of a lot of the assets which you're spending money to develop. So you're getting much more value out of the dollar that you're investing in technology because you're able to use things more easily. That's number one.

Second, you're getting quicker time to market. Because you're able to assemble components more easily, you can extend those components more easily so that as the business changes, you're able to react more rapidly to those changes in the business.

I can give you some specific examples here at Comcast. For example, we have two billing systems-60 percent of customers are billed on one and 40 percent are on the other-mostly as a result of our acquisition of AT&T Broadband. We had applications that needed access to the billing system; developers had to write the same APIs [Application Programming Interfaces] twice to access each of the billing systems.

One of the first things we did was to create what we call a billing services mediation layer. Now the developers write the APIs once, to the service layer, rather than to each billing system. That saves money, but it also gives my staff the opportunity to add functionality into the Web services layer themselves without having to go to my billing vendors, which is a lot more cost-effective and a lot more timely.

And, if at some point in time I need to change anything with my back-end billing systems, I can do it without having to change the other applications that link to it because they are connected to the service layer rather than directly to the billing systems.

How do you distinguish between SOA and enterprise architecture?

I don't believe that service-oriented architecture SOA is enterprise architecture. SOA is an enabling technology, but it's not enterprise architecture. You need to have a vision of your business and describe your business in an enterprise architecture, which can be implemented by a Web services SOA service-oriented architecture or not. I think service-oriented architecture SOA is an enabling technology for that enterprise architecture, but it isn't by itself enterprise architecture. Enterprise architecture is required regardless of whether you implement that by SOA or not.

Source: http://www.cio.com

How will SOA affect my IT group?

How will SOA affect my IT group?

If you have a decentralized company, be prepared for a struggle. Service Oriented Architecture SOA drives centralization. Indeed, it demands it. "You have to have someone heading it up, and you have to have one individual or small team manage the architecture," says Mike Falls, senior system engineer for Fastenal, an industrial and construction supply company. "If each team is left to itself, they may each come up with different ways of building services. You need one group, one set of research and someone to make sure the development groups are sticking to the service development methodology."

As the service portfolio grows, the development process may begin to look like an assembly line. "It becomes a factory," says AEP’s Wissner. "You have these different project teams that you funnel work through, and they can grow and shrink as required."

Once the Service Oriented Architecture SOA factory gets ramped up, expect to add more project managers, business analysts and architects as the productivity of the developers increases, says ProFlowers’ Hall. "Two developers can now do the work of six," he says. "That means the architects and project managers are running to keep up with the output of the engineers. We are probably doing 50 percent more work than we did three years ago."

Those programmers need to understand object-oriented programming and distributed applications—and that means an investment in training. According to the CIO/Computerworld survey, only 25 percent of respondents have the staffs they need for Service Oriented Architecture SOA—49 percent said they are planning or have training programs in place for current staff to bring them up to speed.

Source: http://www.cio.com

How do I know which services will provide the most value for my investment?

How do I know which services will provide the most value for my investment?

When in doubt, start with processes that involve customers, directly affect revenue and address a specific pain point in the business. A 2006 survey by the Business Performance Management Institute found evolving customer needs and preferences to be the top driver in business process change or the introduction of new applications, followed by competitive threats and new revenue opportunities. (Cost savings was a distant fourth.) "Externally facing applications are the ones that provide the most business value, and they have a good set of change requirements that come up very often," says Daniel Sholler, vice president of research for Gartner. "If you can improve those applications by 10 percent, it’s better than improving lower-level applications by 50 percent." Of course, adds Sholler, Service Oriented Architecture SOA may not provide more value than, say, a good packaged application. "But if it’s something you would have to build yourself anyway, you need to do it service-oriented," he says.

Source: http://www.cio.com

How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?

How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?

Architectural planning is time-consuming. Service-oriented development, drawing upon well-known programming principles and widely available technology standards (such as SOAP, HTTP and so on), can happen a lot faster. But the two need to happen in parallel, say experts. "We do development projects as needed, and then on the side we have a longer multiyear project of mapping out the processes and building enterprise-level services," says Kurt Wissner, managing director of enterprise architecture and development for American Electric Power (AEP). "People need to see the benefit of SOA pretty quickly. That’s why I like the project route, because otherwise you don’t have anything tangible to sell to anyone about why you’re doing this."

While it would help to have the architectural plan and the process mapping in place before building the services (to improve the chances for reuse), architecture planning has no short-term payback, which can be devastating. "I tried to boil the ocean at another company and I failed," recalls Wissner. "We did a big multimillion-dollar architecture plan that duplicated what we already had. It didn’t provide much value over traditional point-to-point integration, and we had nothing to show for our efforts. If you start with the entire enterprise, there are too many risks you might fail."

By taking the enterprise planning in smaller chunks at AEP, Wissner can more easily recover from setbacks. "We’ve had hiccups but could take corrective action because the issue wasn’t that big," he says. "If you break it into simpler pieces, it’s more easily digestible."

What are the advantages of SOA?

What are the advantages of SOA?

First, put the benefits of Service Oriented Architecture SOA in perspective. SOA is a scythe that slices through complexity and redundancy. If your company is not large or complex—i.e., more than two primary systems that require some level of integration—it's not likely that SOA will provide much benefit. Lost in all the hype about Service Oriented Architecture SOA today is the fact that the development methodology itself brings no real benefit—it's the effects that it has on a complex, redundant infrastructure that bring the rewards. Architects say there is more work involved in creating a good service-oriented application than there is in doing traditional application integration. (Surveys show consistently that Service Oriented Architecture SOA is being used for traditional application integration at most companies.) So there is actually an extra cost being generated by Service Oriented Architecture SOA development up front. For there to be a benefit from that work, therefore, it must eliminate work somewhere else, because the methodology in and of itself does not create business benefit. Before considering whether SOA has benefits, you first must determine whether there are redundant, poorly integrated applications that could be consolidated or eliminated as a result of adopting SOA. If that's the case, then there are some potential benefits.

To get the entire picture of benefits being sold with Service Oriented Architecture SOA, you have to look at it on two levels: first, the tactical advantages of service-oriented development and second, the advantages of SOA as an overall architecture strategy.

Advantages of service-oriented development:

1. Software reuse. If the bundle of code that constitutes a service is the right size and scope (a big if, say Service Oriented Architecture SOA veterans), then it can be reused the next time a development team needs that particular function for a new application that it wants to build. For example, a telecom company may have four different divisions, each with its own system for processing orders. Those systems all perform certain similar functions, such as credit checks and customer record searches. But because each system is highly integrated, none of these redundant functions can be shared. Service-oriented development gathers the code necessary to create a version of "credit check" that can be shared by all four systems. The service may be a wholly new chunk of software, or it may be a composite application consisting of code from some or all of the systems. Regardless, the composite is wrapped in a complex interface that hides the complexity of the composite. The next time developers want to create an application that requires a credit check, the developers write a simple link to the composite application. They don't have to worry about linking with the individual systems—indeed, they don't need to know anything about how the code has been bundled or where it comes from. All they need to do is build a connection to it.

In a company that constantly builds new systems that rely on similar functionality—an insurance company with many different divisions, each with slightly different products, for example, or a company that is constantly acquiring new companies—the time saved in developing, testing and integrating that same bit of software functionality can add up.

But reuse isn't assured. If developers in other parts of the company don't know that the services exist, or don't trust that they are well built, or development methodologies differ around the company, the service may languish as a one-off. Companies that get reuse have developed governance mechanisms—such as centralized development teams, a single development methodology and service repositories—to increase the chances for reuse.

But sometimes the service just isn't designed properly. Perhaps it doesn't perform enough operations to be widely applicable across the company, or perhaps it tries to do too much. Maybe the developers didn't take into consideration all the different ways that others might want to use the service in applications. Service Oriented Architecture SOA veterans say that sizing services properly—also known as granularity—is as much art as science and that poor granularity can dramatically reduce the possibilities for reuse. Research company Gartner estimates that only 10 percent to 40 percent of services are reused.

2. Productivity increases. If developers reuse services, that means software projects can go faster and the same development team can work on more projects. Integration becomes a lot cheaper (at least 30 percent cheaper, according to estimates by Gartner) and faster, too, taking months off development cycles for new projects. Shadman Zafar, Verizon's senior vice president for architecture and e-services, says his catalog of services lets him skip forming a project team for the development of a phone-line ordering process, because the services necessary to compose the process were already in place. "With point-to-point integration, we would have had a central project team to write the overall integration, and local teams for each of the systems we needed to integrate with. With [the phone-line process], we had a single team that was focused almost entirely on end-to-end testing," he says. That saves time and resources and improves the quality of new applications, because testing is no longer the last hurdle of an exhausting application development process; instead, it's the focus.

3. Increased agility. Even if services will not be reused, they can offer value if they make IT systems easier to modify. At ProFlowers.com, for example, there are no redundant applications or multiple business units clamoring for services. But splitting the flower ordering process into discrete services means each component can be isolated and changed as needed to handle the spikes in demand that occur around holidays, according to ProFlowers CIO Kevin Hall. When ProFlowers had a single, monolithic application handling the process, a single change in the process or a growth in transaction volume (on, say, Valentine’s Day) meant tearing apart the entire system and rebuilding it.

In the new system, a server farm responds to spikes in activity during each phase of the ordering process by transferring storage capacity to the specific service that needs it most. The system is much more predictable now, and there have been no outages since the service-enabled process was rolled out beginning in 2002, according to Hall. "Because we can scale horizontally [more servers] and vertically [splitting up services], I don’t have to buy all the hardware to serve every service at its peak load," he says. "You don’t have to be able to eat the elephant in one bite anymore."

Advantages of an Service Oriented Architecture SOA strategy:

1. Better alignment with the business. SOA is the big picture of all the business processes and flows of a company. It means business people can visualize, for the first time, how their businesses are constructed in terms of technology. When IT projects are put in terms of business activities and processes rather than complex software applications, business people can better appreciate and support IT projects. "When I said we have 18 slightly different versions of 'credit check' buried inside different applications in different agencies," says Matt Miszewski, CIO for the state of Wisconsin, "the agency heads could understand why having all those different versions was a problem, and they could support creating a single version that everyone could use." The grand vision for Service Oriented Architecture SOA is that when IT fully service enables the major processes of a business, business people will someday be able to take control of modifying, mixing and matching the different services together into new process combinations on their own. But that vision is still many years away.

2. A better way to sell architecture to the business (and IT). Enterprise architecture has long been the concept that dared not speak its name. Some CIOs go to great lengths to avoid using the term with their business peers for fear of scaring, alienating or simply boring them to death. Enterprise architecture has always been a big, difficult and expensive undertaking, and its ROI has often been opaque to the business. Standardizing, mapping and controlling IT assets do not make the business obviously more flexible, capable or profitable. As a result, IT architecture efforts often fail or become completely IT-centric. Service Oriented Architecture SOA provides the value to the business that in the old enterprise architecture was rarely more than a vague promise. Reuse, improved productivity and agility in IT and a software infrastructure tuned to specific business processes are the lures to sell an enterprise architecture effort to the business. But remember that architecture is not for everyone. Small companies or highly decentralized companies may not be able to justify a centralized staff of project managers, architects and developers.

Source: http://www.cio.com

How do I know whether I should adopt SOA as a strategy?

How do I know whether I should adopt SOA as a strategy?

Because it is an architectural strategy, Service Oriented Architecture SOA involves much more than merely building software. Creating an architecture based on a portfolio of services asks that CIOs make a compelling case for enterprise architecture, a centralized development methodology and a centralized staff of project managers, architects and developers. It also requires a willing CEO and executive staff to pave the way for IT to dive in to the core business processes of the company. Understanding those processes and getting buy-in on enterprise sharing are the keystones of Service Oriented Architecture SOA-based business transformation.
Governance is critical. For services to be reused across the company, there must be a single, centralized software development methodology so that different areas of the business don't build the same service in different ways or use linkages that are incompatible. There must be a centralized warehouse, or repository, so that developers will know where to look for services—and so IT will know who is using them. The services must be well documented so that developers will know what they are for, how to link to them and the rules for using them. (For example, some companies charge fees to use the services and create performance agreements to make sure the services work well and don't put too much load on the corporate network.)

Most companies that have progressed along the path to Service Oriented Architecture SOA have created a centralized architecture group to choose processes that will be service enabled and to consult with different areas of the company to build the specific services. The centralized group also creates a convenient mechanism for governance. If all service requests have to go through the architecture group, the service development methodologies, projects and performance agreements can be more easily managed.

The companies that have had the most success with Service Oriented Architecture SOA so far are those that always have success with technology: big companies with big IT budgets whose business is technology-based (think telecom and financial services). They also tend to have supportive, technologically sophisticated business leaders. For companies without these advantages, SOA may not be the panacea it’s being made out to be.

For smaller companies, for companies that have made big bets on integrated application suites and for companies that already have solid application integration strategies in place, SOA isn’t a "when," it’s an "if." CIOs need to pursue an Service Oriented Architecture SOA strategy carefully because the service development and architecture planning pieces of SOA are distinct but not independent—they need to be considered and executed in parallel. Services built in isolation, without taking into account the architectural and business goals of the company, may have little potential for reuse (one of Service Oriented Architecture SOA’s most important benefits) or may fail outright.

Source: http://www.cio.com

at's the difference between SOA and web services?

What's the difference between SOA and web services?

SOA Service Oriented Architecture 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.

Source: http://www.cio.com

What is SOA and Service?

What is Service-Oriented Architecture (SOA)?

SOA Service Oriented Architecture 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 SOA 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.

Developers create the abstraction by building a complex wrapper around the bundled code. This wrapper is an interface that describes what the chunk does and how to connect to it. It's an old concept that dates back to the 1980s, when object-oriented programming first appeared; the only difference is that today, the ambition for the size and sophistication of these software objects is far more grand.

For example, at telecom company Verizon, the service called "get CSR" (get customer service record) is a complex jumble of software actions and data extractions that uses Verizon's integration infrastructure to access more than 25 systems in as many as four data centers across the country. Before building the "get CSR" service, Verizon developers who needed that critical lump of data would have to build links to all 25 systems—adding their own links on top of the complex web of links already hanging off the popular systems. But with the "get CSR" service sitting in a central repository on Verizon's intranet, those developers can now use the simple object access protocol (SOAP) to build a single link to the carefully crafted interface that wraps around the service. Those 25 systems immediately line up and march, sending customer information to the new application and saving developers months, even years, of development time each time they use the service.

There are many different ways to connect services, such as custom programming links or integration software from vendors, but since 2001, a set of software communication mechanisms known as web services, which are built upon the ubiquitous World Wide Web, have become an increasingly popular method for linking software components together.

Source: http://www.cio.com

Service-oriented architecture (SOA) definition

SOA Service-oriented architecture definition

A service-oriented architecture SOA is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

SOA Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA, see Prior service-oriented architectures (new window).

Services
If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. See Service (new window).

Connections
The technology of Web services (new window) is the most likely connection technology of service-oriented architectures SOA. Web services essentially use XML (new window) to create a robust connection.

The following figure illustrates a basic service-oriented architecture SOA. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined is explained in Web Services explained (new window). A service provider can also be a service

Source: http://www.service-architecture.com

Road to SOA: SAP to address customer pain

Road to SOA Service Oriented Architecture : SAP to address customer pain by Robert Westervelt

SAP is packaging software and consulting services to steer customers on a smoother path to a service oriented architecture (SOA) and ease the learning process of its NetWeaver development and integration platform.

SAP unveiled an Enterprise Services Architecture Adoption Program that will give customers a series of educational workshops and tools to build a roadmap for using NetWeaver to establish a complete service oriented architecture SOA. The program is being offered in conjunction with SAP products that are built on NetWeaver.

The Enterprise Services Architecture (ESA) concept was introduced by SAP in 2003. It was used to showcase NetWeaver and how companies can upgrade their architectures in a step by step process to build an SOA service oriented architecture.

The workshops will take into account specific company architectures and develop a tailored plan to move to an SOA service oriented architecture. A total cost of ownership discovery session is also included.

SAP is in a foot race with its competitors, Oracle Corp. and Microsoft, to develop products that support an SOA, according to analysts. Getting customers familiar with its NetWeaver platform and educated about its ESA strategy has been the theme emanating for several years from SAP's Waldorf Germany headquarters.

With a saturated ERP market, making inroads by developing an open architecture could create new business for SAP, analysts say. As Oracle Corp. combines the software code it acquired from its recent merger with PeopleSoft, developers on what Oracle calls "Project Fusion" must migrate the code to a more open environment, said Paul Hamerman, vice president of enterprise applications at Cambridge, Mass.-based Forrester Research Inc.

"SAP is further along in its SOA build out strategy than Oracle at this point," Hamerman said. "Fusion is based to a large degree on the code that exists in the E-Business Suite, so developing an open environment will not be easy for Oracle."

SAP hopes a better educated customer base will get more customers developing composite applications and SAP's Master Data management technology. Over the next three years, SAP will dramatically accelerate the revamping of its products, said Jim Shepherd, vice president of research at Boston-based AMR Research Inc.

"The vision of breaking the enterprise application suite into a portfolio of configurable process components has been a key part of SAP's strategy for many years," Shepherd said recently in a research brief to AMR clients. "The company believes it is very important to quickly complete the transition to an [SOA] before competitors like Oracle or Microsoft can bring their next-generation products to market."

Composite apps, called xApps by SAP, snap into place on top of the existing applications its customers may have, regardless of platform or vendor. Composite applications pull together relevant data from across a company's applications and should result in streamline business processes, said Ori Inbar, vice president of product marketing, for SAP NetWeaver.

"By now people understand the value of an SOA and know that it's not easy and want guidance on how to do this," Inbar said.

The ESA Adoption Program will be provided initially by SAP Consulting, but SAP plans to eventually allow its partners to conduct the workshops.

"Changing your architecture into a service oriented architecture is not something you do over night. It's a journey," Inbar said.

Source: http://searchsap.techtarget.com

SOA Service Oriented Architecture

SOAService-oriented architecture(SOA ออกเสียงเป็น "sō-uh" หรือ "es-ō-ā") แสดงถึงมุมมองของสถาปัตยกรรมซอพต์แวร์ ถูกกำหนดโดยใช้รูปแบบของ loosely coupled ( ) เพื่อการบริการของซอพต์แวร์ เพื่อสนับสนุนความต้องการของกระบวนการทางธุรกิจ และซอพต์แวร์ที่สนับสนุนต่อยูสเซอร์ ในสภาวะแวดล้อมของ SOA ทรัพยากรบนระบบเครือข่ายสามารถหาประโยชน์ของบริการได้อย่างอิสระ ซึ่งสามารถเข้าถึงได้โดยปราศจากความรู้เกี่ยวกับหลักการในการพัฒนาบนแพลทฟอร์มต่างๆ

SOA service-oriented architecture เป็นสถาปัตยกรรมที่ไม่สนใจเทคโนโลยีใดๆ โดยเฉพาะ และอาจถูกพัฒนาโดยใช้บนขอบเขตที่กว้าง ของความสัมพันธ์บนระบบพื้นฐานที่หลากหลาย เช่น RPC, DCOM, ORB หรือ Web Services

SOA service-oriented architecture สามารถพัฒนาโดยปราศจากโปรโตคอลใดๆ เช่น ใช้ระบบไฟล์เพื่อสื่อสารกับข้อมูลให้ตรงกัน สำหรับกำหนดส่วนติดต่อที่เลือกไว้ระหว่างการประมวลผลของข้อมูลที่ตรงกันของหลักการ SOA ปัจจัยหลักคือความเป็นอิสระของบริการกับการกำหนดส่วนติดต่อซึ่งสามารถเรียกเพื่อกระทำงานเหล่านั้นในทางพื้นฐาน ปราศจากความรู้ที่มีในบริการนั้นสำหรับการเรียนแอพพลิเคชั่น ปราศจากปราศจากความรู้ความเข้าใจของแอพพลิเคชั่นว่าแท้จริงแล้วบริการนั้นมันทำงานอย่างไร

SOA สามารถพิจารณาถึงรูปแบบของสถาปัตยกรรมบนระบบสารสนเทศซึ่งสามารถสร้างแอพพลิเคชั่นที่ก่อให้เกิดการรวมกันระหว่างบริกการทาง loosely coupled และ interoperable บริการเหล่านี้กระทำบนพื้นฐานของรูปแบบที่ถูกกำหนด เช่น WSDL ซึ่งเป็นอิสระกับแต่ละแพลทฟอร์มและภาษาโปรแกรม การกำหนดส่วนติดต่อ มีการแบ่งแยกแต่ละส่วนเมื่อมีการเปลี่ยนแปลงส่วนใดส่วนหนึ่งจะไม่ส่งผลกับส่วนอื่นๆ และสามารถจัดการได้ง่าย เพื่อกำหนดตามการบริการแต่ละภาษา
ระบบ SOA-compliant เป็นอิสระกับการพัฒนาเทคโนโลยีและแพลทฟอร์มต่างๆ เช่น Java, .NET เป็นต้น บริการที่เขียนในภาษา C# ที่รันบนแพลทฟอร์มของ .Net และบริการที่เขียนในภาษา Java ที่รันบนแพลทฟอร์มของ Java EE สามารถใช้บนแอพพลิเคชั่นเดียวกันร่วมกันได้ เนื่องจาก แอพลิเคชั่นทำการรันได้บนทั้งสองแพลทฟอร์มซึ่งสามารถใช้งานบริการเพื่อรันบน Web Services อื่นๆได้ ซึ่งแสดงถึงความง่ายและสะดวกที่นำกลับมาใช้ใหม่

SOA สนับสนุนการรวบรวมหลายแพลทฟอร์มให้เป็นหนึ่งเดียว ภายในระบบที่มีความซับซ้อน แต่ SOA service-oriented architecture ไม่ทำการระบุหรือจัดให้มีวิธีการหรือเป็นเฟรมเวิร์คสำหรับเอกสารต่างๆหรือบริการนั้นๆ

ในภาาษาระดับสูง เช่น BPEL และรายละเอียดปลีกย่อย เช่น WS-Coordination เป็นส่วนขยายเพื่อส่งเสริมหลักการการบริการ โดยจัดให้มีวิธีการเพื่อกำหนดและสนับสนุน orchestration เพื่อปรับเปลี่ยนบริการโดยทั่วไปให้ใช้งานได้กับบริการทางธุรกิจ ซึ่งสามารถนำกลับมารวมไว้ด้วยกันในกระบวนการ workflow และทางธุรกิจ ซึ่งถูกพัฒนาใน composite applications หรือ portals

อ้างอิง

http://en.wikipedia.org/wiki/Service-oriented_architecture

SOA WebServices การทำให้โปรแกรมต่าง ๆ ทำงานร่วมกันได้

Service Oriented Architecture SOA WebServices การทำให้โปรแกรมต่าง ๆ ทำงานร่วมกันได้

ในปัจจุบันองค์กรต่าง ๆ จำเป็นต้องมีการทำงานร่วมกันหรือแลกเปลี่ยนข้อมูลกัน เทคโนโลยีที่จำเป็นต่อการทำให้โปรแกรมแอพพลิเคชั่นต่าง ๆ สามารถทำงานเข้าด้วยกันและแลกเปลี่ยนข้อมูลเข้าด้วยกันจึงมีความสำคัญเป็นอย่างยิ่ง เทคโนโลยีหนึ่งที่เข้ามาเป็นส่วนหนึ่งของการดำเนินการทำให้โปรแกรมต่าง ๆ ทำงานด้วยกันได้คือ SOA (Service-Oriented Architecture) หลายคนสงสัยว่า SOA คืออะไร มีข้อดี และข้อเสียอย่างไร SOA กับ Web Services คือเทคโนโลยีตัวเดียวกันหรือไม่ ถ้าไม่ใช่ มีความสัมพันธ์กันอย่างไร

Service-Oriented Architecture SOA เป็นกลุ่มของเซอร์วิสที่ให้บริการผ่านทางเน็ตเวิร์กโดยที่เซอร์วิสนั้นสามารถถูกนำไปใช้ในแพลตฟอร์มใด ๆ ก็ได้ ข้อดีคือ ทำให้เซอร์วิสนั้นมีการถูกนำไปใช้ในซอฟต์แวร์อื่น ๆ ได้ง่าย โดยไม่ต้องมีการแก้โค๊ดให้เหมาะสมกับแพลตฟอร์มที่แตกต่างกันออกไป ข้อด้อยคือ ในแง่ของผู้ให้บริการเซอร์วิส ต้องมีการลงทุนเพิ่มเป็นพิเศษในการออกแบบและพัฒนาซอฟต์แวร์เพื่อให้ถูกนำไปใช้ได้ง่ายและจะต้องมีวิธีการที่ดีในการรองรับการเปลี่ยนแปลงของความต้องการของซอฟต์แวร์นั้น แต่้ถ้าหากว่ามีจำนวนผู้เรียกใช้เซอร์วิสนั้นเป็นจำนวนมาก และผู้ใช้เซอร์วิสเรียกใช้เซอร์วิสจากแพลตฟอร์มที่แตกต่างกันออกไป การลงทุนนี้ก็จะคุ้มค่า

Service-Oriented Architecture SOA กับ Web Services ไม่ใช่เป็นสิ่งเดียวกัน SOA สามารถถูกพัฒนาโดยใช้เทคโนโลยีอย่างอื่นที่ไม่ใช่ Web Services และ การพัฒนา Web Services ก็ไม่จำเป็นต้องได้ซอฟต์แวร์ที่เป็น SOA

SOA เป็นตัวกำหนดรูปแบบของซอฟต์แวร์ที่เป็นการให้บริการเซอร์วิสที่เป็นส่วนหนึ่งของระบบแบบกระจายที่ไม่ใช่เป็นระบบแบบรวมศูนย์ ส่วน Web Services เป็นเทคโนโลยีซึ่งสามารถนำไปพัฒนาเพื่อให้เกิด SOA Service-Oriented Architecture ที่เป็นรูปธรม

ที่มา

Rag Ramanathan, "Make Application Integration Easy"

http://www.ftponline.com/weblogicpro/2004_09/magazine/features/rramanathan/default_pf.aspx#

Successfully Planning for SOA - Part 1

Successfully Planning for SOA : Taking a strategic approach to realizing SOA (Part 1) by David Groves

As you continue to develop your IT architecture, it becomes clear that the route to achieving real business benefits requires a fundamental change in the way you think about system design. In this article on services-oriented architecture (SOA), I'll share with you helpful tips, insights, and a domain model to help you plan this change, and ensure the success of your SOA implementation.

SOA: A New Way of Thinking

Albert Einstein once said, "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." In today's enterprise computing, this suggests that the challenges IT faces in delivering successfully to the business cannot be overcome without changing the way we think about IT. For developers and enterprise architects alike, services-oriented architecture SOA provides a structure for that change. The question then becomes: How do we migrate to that new level? How do we prepare for such a fundamental change? How do we do so in the most cost-effective, least organizationally traumatic way possible? The answers begin with proper planning.

SOA services-oriented architecture is not so much a technology as it is a way of thinking. It is bold agenda for infrastructure reformation and represents a culture shift in how we employ technology and work together. Its sudden popularity is less a product of hype than it is recognition of SOA services-oriented architecture as an evolution towards providing closer alignment between our business and our IT systems. Also, that evolution is stunning and far reaching in its implications for the success of our enterprise.

What Is SOA, Really?

Service-oriented architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs.

A service is a module of code, governed by a service level agreement, which can be accessed via a standards-based interface. Each service represents a piece of functionality that maps explicitly to a step in a business process. Services can either be written from scratch or mined by exposing modules of existing system functionality from previously "silo-ed" applications.

Over time, a catalog of services can be built up, allowing business functionality to be fluidly accessed and reused across many different systems. In this way, SOA services-oriented architecture can eliminate duplicate data, rekeying of information, and human error at the tactical level while enabling strategic change - for example, by creating a single view of the customer, and in the process opening up new possibilities for cross-sell, up-sell, and offering services for a more attractive user experience.

New Infrastructure Paradigm

Part of the paradigm shift of SOA is a move from application infrastructure to service infrastructure. Prior to SOA services-oriented architecture, applications were organized into "silos" with point-to-point connections. SOA uses the same back-end application engines and middleware, but leverages a converged Service Infrastructure Layer (Figure 1).

Implementing SOA

As you begin to implement SOA, use the following formula:

• Think Strategically, Execute Tactically: Start by realizing a single-core process with simple, agnostic services that span multiple business units
• Top-down: Identify the services required to support this single-core process
• Bottom up: Identify functions in existing systems that could be exposed as services to support this process
• Infrastructure Services: Identify common supporting functionality requirements
• Expand Slowly: Technically challenging projects may be undertaken concurrently after initial projects have proven successful
• Build an Application Catalog: On a project-by-project basis, harvest and reuse service modules, thereby reducing your cost curve over time
• Focus on Benefits: Phase projects in order of ROI, in stages that include plateaus for consolidation

Using the BEA Domain Model To Plan Effectively

• To be successful, SOA requires IT and the business to work together in new ways. As you plan for services-oriented architecture SOA, you will need to create an effective balance between the technical and nontechnical elements. To this end, BEA has developed a domain model (Figure 2) to help guide you through planning the six key areas that must be given equal consideration to ensure a successful implementation. The first three (Business Strategy and Process, Architecture, and Cost and Benefits) are a good place to begin the planning process.
• Business Strategy and Process: Mapping services-oriented architecture SOA to Your Business

SOA maps IT functions to your business processes, thereby enabling business improvement over time. This mapping process is best expressed as follows:

Analyze: Study processes and identify the supporting functionality required
Develop: Harvest functionality from existing IT assets, develop new functionality, and ensure that all services have clear service-level agreements.
Utilize: Orchestrate services into processes, measure alignment with strategy, and identify opportunities for optimization

Architecture: Defining Long-term Needs
Establish a reference architecture for your IT organization. This is not a current state diagram, but a long-term vision to build against, which should incorporate a two-to-three year architectural vision of where your business is heading. Take the time to define your architecture's guiding principles and policies, but be wary of making those guidelines an end unto themselves. The flexibility and modularity of the services-oriented architecture SOA system should take first priority.

Cost and Benefits: Demonstrating Immediate Business Value
SOA is designed to hit the ground running, and it is important to prioritize the development of services in a cost-benefit order, so that your services-oriented architecture SOA shows ROI from the start. With careful planning, "start-up" costs can largely be absorbed into existing budgets. Over time, the reuse of service modules ensures a lower start-up cost for each new business application. Ensure measurability by setting your baseline at the beginning of your implementation, and avoid the need for backfilling down the road.

Using the SOA Maturity Model
BEA's SOA Maturity Matrix will help you to monitor your services-oriented architecture SOA rollout, thus helping you to monitor your progress against the different phases of development. This matrix is divided into three stages: exploring, expanding, and Exploiting. To assess your architecture's maturity level, you may use BEA's Online Self-Assessment Tool (www.bea.com/soa).

Conclusion
It has been my goal in this article to offer you some pointers for organizing successful services-oriented architecture SOA planning, and my belief is that in taking this approach you can achieve the smoothest SOA rollout possible, and move your organization on to the next level of your development and business agility. For more information on BEA's SOA solutions, please visit www.bea.com.

Source: http://soa.sys-con.com

Successfully Planning For SOA, Building Your SOA Roadmap - Part2

Successfully Planning For service-oriented architecture SOA, Building Your SOA Roadmap (Part 2) by Stephen Bennett

In this second article about service-oriented architecture (SOA), I offer a concrete plan, along with tips and insights, to help you build an effective SOA roadmap, and to help ensure the success of your service-oriented architecture SOA initiative.

Any great journey starts with a goal or destination, and your organization's decision to implement service-oriented architecture SOA is no different. However not unlike the pioneers who set off west in their wagons, you may start with only a vague idea of what awaits you, or how you might get to your destination. To be successful, you must assess your strengths and weaknesses, establish clear direction, choose a route, and then consistently reassess that route as you follow it. You must, to put it simply, create your own unique map for your journey.

What Is an SOA Roadmap and Why Do You Need One?

Service-oriented architecture SOA is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs. The benefits of SOA will only be realized if the balance between long-term goals and the shorter-term needs of the business are preserved. This balance can be maintained by instituting a set of organizational, financial, operational, design, and delivery practices from the outset of your SOA initiative. However it is important that these culture-changing disciplines are deployed in an incremental and iterative fashion, rather then a "big bang" approach, which allows for an organizational learning curve. In essence, an SOA roadmap is an iterative and incremental way to capture (and recapture) your organization's unique plan as you progress.

Your SOA Roadmap should contain three critical characteristics:

Maturity: Treat your service-oriented architecture SOA Roadmap as a "living document" that continually captures experiences and lessons learned. As your SOA roadmap matures, your SOA initiative reaches higher levels of sophistication, in a controlled manner. The creation of an SOA roadmap begins with an assessment of your organization's current capabilities and disciplines that are applicable to service-oriented architecture SOA. This process can be initiated by using BEA's Online Self-Assessment Tool (www.bea.com/framework.jsp?CNT=index.htm&FP=/content/solutions/soa/).

Scope: A complete SOA roadmap should encompass all six domains (see Figure 1). These domains, while distinct, are interrelated and interdependent. Executing on each domain is fundamental to the success of an enterprise-wide SOA initiative. The service-oriented architecture SOA roadmap should clearly delineate the boundaries of your SOA initiative and establish a transparent and flexible timeline for achieving SOA goals. These goals should be broken down into manageable phases, which can then be realized in an iterative and incremental manner.

Quality: By applying a "Learn and Adapt" process at each milestone, and by being both iterative and incremental, your roadmap will remain relevant throughout the service-oriented architecture SOA initiative. To ensure your SOA roadmap's quality, communicate and validate it with all stakeholders, soliciting feedback and buy-in from all quarters.

How to Build an SOA Roadmap

There are four phases to developing your service-oriented architecture SOA roadmap: SOA planning, SOA maturity assessment, SOA future vision, and SOA roadmap definition.

SOA Planning
During this phase, your service-oriented architecture SOA initiative is organized and defined. Stakeholders are brought into the process through communications and briefings, and mutually agreed upon priorities and parameters are set. Because this phase involves employees across your organization, clear and ample communication is critical. During this phase you will:

Define the scope of SOA service-oriented architecture
Establish boundaries and alignments with other IT initiatives
Appropriately showcase the business justification for SOA
Show alignment of existing and future business initiatives

SOA Maturity Assessment

During the service-oriented architecture SOA maturity assessment phase, you will establish a metric for where you are today. Here you will define what services and capabilities you currently have that can serve as a starting point for SOA, as well as identify projects that might serve as foundation projects. Through a series of interviews and questionnaires, your teams should examine the various domains - analyzing, base-lining, and validating the "as-is" current situation for each. Use of BEA's domain model allows you to structure your examination of the following:
Business Strategy and Process: A top-down view of business strategies and processes
Architecture: A review of current architectures, policies, and standards
Cost and Benefits: Overview of existing cost structures and benefits cases
Building Blocks: An analysis of existing services, processes, tools, and technologies
Projects and Applications: Review of existing systems and in-flight and planned projects
Organization and Governance: Analysis of existing governance structures and policies

SOA Future Vision

In this phase, teams use workshops to determine and define the future desired "should-be" state and ensure cross-organizational buy-in:
Business Strategy and Process: Correlation of service-oriented architecture SOA future vision with business strategies and processes
Architecture: Architecture guiding principles, requirements, policies, standards, and reference architecture
Cost and Benefits: Metrics and measurement requirements
Building Blocks: Shared services infrastructure requirements, standardize tools
Projects and Applications: SOA mapping to projects and applications
Organization and Governance: Governance and compliance structures and policies

SOA Roadmap Definition

This phase is where the service-oriented architecture SOA roadmap is initially defined. A complete gap analysis should be performed for your corporation's SOA goals and appropriate timelines, based on the information gathered in the previous three phases. Near-term events will be more detailed, while later events will be more fluid - so that they might incorporate lessons learned as you move forward.
Business Strategy and Process: Opportunity alignment by business value
Architecture: Near-, medium-, and long-term reference architecture roadmap
Cost and Benefits: Roadmap of future metrics, cost structures, and benefits cases
Building Blocks: Prioritization of shared services strategy and standardized processes
Projects and Applications: Project and application impact
Organization and Governance: Proposed governance structures and policies
Your service-oriented architecture SOA roadmap should be treated as a "living document" that continually captures experiences and lessons learned. As your roadmap matures, your SOA initiative will reach higher levels of sophistication in a controlled manner (see Figure 2).

Conclusion
The goal of this article is to provide you with a framework for creating your own SOA roadmap, and an explanation of why that roadmap is so important for your service-oriented architecture SOA initiative. Your roadmap is your guide for what to develop, when to develop, and when to deploy what you've developed, and should be your single most powerful tool for a smooth deployment of service-oriented architecture SOA. For more information on BEA's SOA solutions, please visit www.bea.com/soa.

References
BEA Domain Model Whitepaper (PDF): http://contact2.bea.com/bea/www/soarc/ login.jsp?PGM=1&PC=10SOSO4
Successfully Planning for SOA: http://contact2.bea.com/bea/www/soarc/ login.jsp?PGM=1&PC=10SOSO4

Source: http://webservices.sys-con.com

Middleware and SOA Vendors

Middleware and SOA Service Oriented Architecture Vendors

Over fifteen vendors have established themselves on the telecommunications middleware and service oriented architecture scene in recent years.

In this section, Dittberner analyzes leading middleware companies with an analysis of:
Historical expertise and background
Specific areas of strength
Significant customers and partnerships
Key products
Differentiators that make the company standout
Estimate of the company's revenue assurance revenue for 2004

The vendor profiles and product/service specs are a great time-saver: they deliver the kind of information you'd otherwise have to spend weeks tracking down. A list of vendors profiled follows:

Amberpoint BEA Systems Cape Clear DataPower IBM Iona IP Value Microsoft Nakina Systems Nokia Corporation Sonic Software Systinet TIBCO Software Times Ten/Oracle Vitria webMethods

SAP Enterprise SOA for Banking

SAP for Banking: Making the Move to Enterprise SOA in the Banking Industry

The banking industry is facing major challenges today – global consolidation, cross-border mergers, the break up of the value chain, and new regulatory requirements. One of the prerequisites for successfully managing these challenges is a flexible and agile IT environment.

Blueprint for Greater Adaptability

Using enterprise SOA, a business-driven approach to service-oriented architecture (SOA), you can introduce a new level of flexibility and adaptability into your business systems – step-by-step. Enterprise SOA service-oriented architecture provides services and functionality that can be readily assembled and rearranged to enable new processes and provide innovative business solutions.

SAP delivers enterprise SOA service-oriented architecture through our business process platform for banking – and enterprise SOA-enabled business functionality from SAP and ISV partners – to support core industry processes. Because business functionality is linked and process-enabled within the platform, you get both:

Conventional advantages of standardized, packaged software, including out-of-the-box capability and high performance, scalability, and resilience
The promise of SOA service-oriented architecture : re-combination and reuse of services and business functionality, software upgrade paths, and the flexibility to adapt to business needs
The bottom line: You get all the advantages of standard packages from SAP and ISV partners without the inflexibility or cost typically associated with ongoing change.

Banks Collaborate with SAP on Enterprise SOA Initiative

CIOs and IT architects from major stakeholders in the financial services industry are collaborating with SAP – through our industry value network (IVN) for banks – to shape the future of industry service-oriented architectures that will power the next generation performers. Launched in September 2005, the IVN engaged leading banks throughout the world, including ABN Amro, Absa, Banca Intesa, Barclays, Banco Bilbao Vizcaya Argentaria (BBVA), Credit Suisse, Deutsche Postbank, ING, Nordea, and Standard Bank, with the goal of accelerating the transition from traditional to service-oriented architectures.

Currently, the IVN is evolving into an independent and open association comprising retail, private, and wholesale banks, as well as software and service providers. Members contribute by fostering service-oriented architectures for the industry within an independent industry body – while gaining first-hand knowledge of leading-edge enterprise SOA projects.

Source: www.sap.com

SAP Enterprise SOA Services

Services Program Innovations: Enterprise SOA Services

Enterprise service-oriented architecture (enterprise SOA) is a blueprint for an adaptable, flexible, and open IT architecture for developing services-based, enterprise-scale business solutions.

But enterprise Service Oriented Architecture SOA requires more than just software or technology. It also demands experience, expertise, and the services, methodologies, and support that ensure an effective enterprise SOA strategy

Enterprise SOA services complete SAP's holistic approach to enterprise Service Oriented Architecture SOA. These offerings combine a broad range of consulting services, implementation methodologies, education offerings, tools, and ongoing support. Enabling you to master the business and technical aspects of your enterprise SOA strategy and ensure that enterprise SOA delivers the results you want.

Services that Deliver Value

Enterprise Service Oriented Architecture SOA services deliver real value to your organization, including:

An effective enterprise SOA strategy – You get the knowledge, services, and tools you need to design and execute an enterprise SOA strategy that meets your business goals – with the appropriate governance and quality measures built-in.
Fast time to value – Enterprise SOA services deliver proven methodologies, best practices, and tools to help you move rapidly from strategy to execution.
Competitive applications and processes – With enterprise SOA services, you can be sure that your software and business scenarios are supported and maintained with SAP quality assurance.
Business and IT alignment – Enterprise SOA services give you the expert guidance you need to close the gap between your business and IT strategies.
Optimized knowledge transfer – You benefit from education and certification that ensure your teams are equipped to build and run effective business processes in your new architecture.

Learn more about enterprise SOA and how it can benefit your organization.
Your Resource Center

Additional Resources
Learn how you can benefit from enterprise SOA services by reading brochures and customer successes. Access the resources. Want to learn more? Contact SAP for more information.

Source: www.sap.com

SAP Enterprise SOA

SAP Enterprise Service-Oriented Architecture (Enterprise SOA)

Enterprise Service Oriented Architecture SOA is a blueprint for an adaptable, flexible, and open IT architecture for developing services-based, enterprise-scale business solutions. With SAP NetWeaver as a technical foundation, enterprise Service Oriented Architecture SOA moves IT architectures to higher levels of adaptability – and moves companies closer to the vision of real-time enterprises by elevating Web services to an enterprise level.

An enterprise service is typically a series of Web services combined with business logic that can be accessed and used repeatedly to support a particular business process. Aggregating Web services into business-level enterprise services provides a more meaningful foundation for the task of automating enterprise-scale business scenarios.

Source: www.sap.com

What is IBM SOA governance?

Service Oriented Architecture SOA governance is an extension of IT governance that focuses on the lifecycle of services and composite applications in an organization’s service-oriented architecture SOA. The function of SOA governance is to define:

Decision rights for the development, deployment and management of new services.
Monitoring and reporting processes for capturing and communicating governance results. Because Service Oriented Architecture SOA applications are intrinsically fragmented, they introduce new governance challenges. But with the proper policies, principles, standards, procedures and processes in place, businesses can realize the full benefit of service orientation. An effective Service Oriented Architecture SOA governance platform not only helps business and IT teams better identify which projects contribute most to business goals, but it also empowers employees to work and collaborate more efficiently by clearly defining their roles and responsibilities.

What is service lifecycle management?

Once the Service Oriented Architecture SOA governance framework is implemented, it will be used in the model, assemble, deploy and manage phases within the SOA lifecycle. Related to the operational aspects of implementing SOA governance, service lifecycle management addresses how services will be developed, deployed and managed.

Service lifecycle management focuses on the development and deployment of services. SOA governance supplies the decision rights, processes and policies for those activities. Once a service is deployed, there must be management aspects in place to control and monitor the service.

Within service lifecycle management there is a set of functions that will need to be in place and governed to ensure that the value proposition of Service Oriented Architecture SOA, particularly reuse and cost reduction, is achieved.

For more information on how to advance your SOA governance procedures, visit: ibm.com/software/solutions/soa/entrypoints/advancing_soa_governance.html

Service Oriented Architecture SOA Quality Management is the next component of SOA Governance and Service Lifecycle Management

March, 2006 - IBM announced our SOA Governance strategy and direction and tooling
October 2006 - Service Lifecycle Management was added to detail how SOA Governance will be operationalized within the SOA Lifecycle.
December 2006 - IBM featured Empowering the ‘A’ in SOA, which included a number of new and updated products targeted at approach to Service Lifecycle Management Architecture component.
Today - IBM is adding SOA Quality Management to our SOA Governance and Service Lifecycle Management
The announcement today focuses on extending the overall SOA Governance and Service Lifecycle Management capabilities with a set of new Rational test tools and updates to Tivoli products and GTS (Global Technology Services) Offerings.

Why is Governance important to SOA

The increased flexibility and cross-organizational nature of business services that SOA facilitates, requires that organizations establish a framework to implement active decision-making, accurate tracking, improved serviceability and better communication.

SOA governance is the mechanism to ensure that the decision making structure is solid, relationships between services and parties are managed and that there is compliance with the laws, policies, standards and procedures under which an organization operates.

Specifically SOA governance

Creates higher return from focused SOA investments
Aligns IT and business strategies, creates communication paths
Reduces coordination costs: less time wasted due to poorly-managed conflicts
Institutes efficient and effective decision making and clarity executing roles and accountability
Measures effectiveness of SOA
An enterprise that fails to realize the importance of an effective governance structure may not stand to benefit much from a SOA transition.

Source: www.IBM.com

Oracle SOA Governance

Comprehensive Service Oriented Architecture SOA Governance Capabilities from Oracle. Service Oriented Architecture SOA governance is the key to realizing your SOA goals. It defines and enforces the set of policies, procedures, roles, and responsibilities within your enterprise to guide your SOA-related behavior and deliverables. Proper Service Oriented Architecture SOA governance assures an organization will realize the important benefits of SOA—increased business agility, protection of IT investments, and greater business and IT alignment.

ORACLE SOA GOVERNANCE CAPABILITIES
Oracle Fusion Middleware's SOA Service Oriented Architecture offerings provides a comprehensive set of capabilities to define and enforce SOA governance:

Identify, categorize, version, and publish services
Provide service change notifications to developers and applications
Securely view available services within the enterprise and govern the provisioning of new services
Centrally manage security polices and service-level agreements, including authentication, authorization and encryption policies
Centrally manage service-level agreements for performance, guaranteed response time, and high availability and failover on services
Out-of-the-box functionality to implement common governance requirements for business process auditing and canonical data models; and
Metadata repository services to capture and track service interactions and store SOA artifacts and metadata for Web services, service orchestrations and policies.

COMPONENTS
Oracle SOA Suite—A comprehensive SOA offering that includes policy definition and enforcement agents with metadata repository services and APIs for governing service interactions and orchestrations
Oracle Service Registry—A secure UDDI v3-compliant enterprise registry for service lifecycle management
Oracle JDeveloper—An integrated SOA development environment with design-time governance features for service development

Source: www.Oracle.com

Find out about some WebLogic techonologies

Find out about some WebLogic techonologies by Groshan Fabiola

Some people using Oracle need to know about BEA technologies, one of the SOA Service Oriented Architecture technologies, such as BEA WebLogic Server, WebLogic Portal, WebLogic Integration, WebLogic Workshop, and Liquid Data for WebLogic. Because there are no use case realizations to be detailed in the Logical View, the Logical Keep in mind that an application should be constructed so that any component only accesses components within its layer or any lower layer. Exceptions to this constraint should be very rare and well justified. Components are allowed to access lower layers that are not adjacent.

For example, a component in the Presentation and Interface layer may access a component in the Business Logic layer directly without using any component in the Business Process layer. However, it is important to remember that the layers exist for a reason and should not be bypassed arbitrarily.

It is helpful to know that the presentation and Interface layer is responsible for providing the interface to the application. This might be in the form of a browser interface for a web or portal application or a programmatic interface for a rich client or another system..

Keep in mind that a web logic service, a component of the Presentation layer, can receive a callback from a custom Java control, a component of the lower Business Logic layer. However, callbacks are a response channel set up by a higher level component for a lower layer component it invokes. Also, the higher layer invites callbacks and explicitly provides handlers for the callbacks it receives. Consequently, callbacks adhere to the inter-layer communication rules and, in fact, provide a simple mechanism for asynchronous communication between mechanisms.

Also good to know if you are interested in WebLogic is that fact that components of the Business Logic layers can be exposed in the Presentation and Integration layer through programmatic interfaces. Exposing a programmatic interface allows the application to participate as a supplier in a Service-Oriented Architecture SOA. The Data Access and Integration layer allows this application to consume services provided by other systems in an Service-Oriented Architecture SOA. Therefore, this application architecture facilitates a true Service-Oriented Architecture SOA where business logic and business processes can be shared between applications, thereby facilitating composite application construction.

Also, web interface provides the simplest user interface into the application. The web browser client application is the platform that hosts the user interface for all web applications. Content displayed in the browser is mostly static, except for client-side processing driven by JavaScript. Client-side processing is usually leveraged to do light initial data validation or to visually enhance the user interface.

Also, it is good to know that a portal interface gives users a single point of access to applications and information in a unified interface. Also, a portal interface can provide content and applications to multiple audiences with reusable portal resources. A portal interface also allows large amounts of data to be organized and accessed easily. A programmatic interface allows other applications to access data, business processes, and business WebLogic.

About the Author
For more information about Oracle consulting or even about Oracle applications and especially about Oracle licenses please review one of these links.

Source: www.goarticles.com

IBM Tivoli Framework SOA Infrastructure Tools

IBM Tivoli Framework SOA Infrastructure Tools

IBM Tivoli Management Framework (TMF), one of the SOA Service Oriented Architecture Infrastructure Tools, is a systems management platform from IBM (previously Tivoli Systems, Inc., acquired by IBM in 1995 and moved into IBM's Software Group division). The Framework is a CORBA-based architecture that allows the platform to manage large numbers of remote locations or devices.

The framework was a kind of best-practices paradigm. Several products used the TMF but it is going to be replaced by SOA techniques over time.[citation needed]

IBM Products that use TMF

IBM/Tivoli Distributed Monitoring Classic (DM) - Provides agent based monitoring capabilities. Still widely used by customers. Followup: IBM/Tivoli Monitoring (formerly Candle) and IBM/Netcool OMNIBus family.
IBM/Tivoli Enterprise Console (TEC) - Provides enterprise class event management handling and correlation. Still widely used by customers. A possible followup: IBM/Tivoli Netcool OMNIBus family.
IBM/Tivoli Configuration Manager - Provides hardware and software Inventory and Software Distribution capabilities. Followup as a non-TMF version or incorporated with other software with similar functionality.
IBM/Tivoli Remote Control - Includes VNC-like capabilities. Likely to be replaced by a non-TMF version.
IBM Tivoli NetView - for network management; utilizes SNMP; can use TMF or not. Possible followup: IBM/Tivoli Netcool Precision

HyPerformix SOA Infrastructure Tools

HyPerformix SOA Infrastructure Tools

HyPerformix, Inc., based in Austin, Texas, United States is an enterprise software company specializing in Capacity Management and Performance Engineering software for computer servers, IP networks, storage, SOA Service Oriented Architecture infrastructure tools, and applications. HyPerformix’s solutions solutions predict and prevent IT capacity and performance issues.

HyPerformix Products

The following enterprise software solutions are developed by HyPerformix:

HyPerformix IPS Capacity Manager [1]
HyPerformix IPS Performance Optimizer [2]
HyPerformix IPS Performance Optimizer for SAP [3]
HyPerformix IPS Performance Designer [4]
HyPerformix IPS Data Manager[5]

HyPerformix History
strong>
HyPerformix, a privately-held company based in Austin, Texas, was originally formed in the early seventies to conduct scientific and engineering research. In 1989, the company began to develop and market simulation-modeling products to the engineering community. In 2000, the company applied the general-application simulation modeling technology specifically to IT-related enterprise performance optimization and capacity management solutions.

SOA and Business Architecture

Service Oriented Architecture SOA and Business Architecture

One area where SOA has been gaining ground is in its power as a mechanism for defining business services and operating models and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using Service Oriented Architecture SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. At the heart of Service Oriented Architecture SOA planning is the process of defining architectures for the use of information in support of the business, and the plan for implementing those architectures (Enterprise Architecture Planning by Steven Spewak and Steven Hill). Enterprise Business Architecture should always represent the highest and most dominant architecture. Every service should be created with the intent to bring value to the business in some way and must be traceable back to the business architecture.

Within this area, SOMA (Service-Oriented Modelling and Architecture) was announced by IBM as the first SOA-related methodology in 2004. Since then, efforts have been made to move towards greater standardization and the involvement of business objectives, particularly within the OASIS standards group and specifically the Service Oriented Architecture SOA Adoption Blueprints group. All of these approaches take a fundamentally structured approach to Service Oriented Architecture SOA, focusing on the Services and Architecture elements and leaving implementation to the more technically focused standards.

Criticisms of SOA

Criticisms of Service Oriented Architecture SOA

Some criticisms of Service Oriented Architecture SOA are based on the assumption that SOA is just another term for Web Services. For example, some critics claim SOA results in the addition of XML layers introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC) applications could run slower and require more processing power, increasing costs. Most implementations do incur these overheads, but Service Oriented Architecture SOA can be implemented using technologies (for example, Java Business Integration (JBI)) which do not depend on remote procedure calls or translation through XML. However, there are emerging and open-source XML parsing technolgies, such as VTD-XML, and various XML-compatible binary formats (http://vtd-xml.sf.net/persistence.html) that promise to significantly improve the Service Oriented Architecture SOA performance.

Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. The drawback of this constraint is that it could reduce the overall scalability of the service provider because it might need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.

Another concern is that WS-* standards and products are still evolving (e.g., transaction, security), and Service Oriented Architecture SOA can thus introduce new risks unless properly managed and estimated with additional budget and contingency for additional Proof of Concept work.

An informal survey by Network Computing placed Service Oriented Architecture SOA as the most despised buzzword (November 2006).

Some critics feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc).

A SOA being an architecture is the first stage of representing the system components that interconnect for the benefit of the business. At this level a SOA is just an evolution of an existing architecture and business functions. SOAs are normally associated with interconnecting back end transactional systems that are accessed via web services.

The real issue with any IT "architecture" is how one defines the information management model and operations around it that deal with information privacy, reflect the business's products and services, enable services to be delivered to the customers, allow for self care, preferences and entitlements and at the same time embrace identity management and agility. On this last point, system modification (agility) is a critical issue which is normally omitted from IT system design. Many systems, including Service Oriented Architecture SOAs, hard code the operations, goods and services of the organisation thus restricting their online service and business agility in the global market place.

Adopting SOAs is therefore just the first (diagrammatic) step in defining a real business system. The next step in the design process is the definition of a Service Delivery Platform (SDP) and its implementation. It is in the SDP design phase where one defines the business information models, identity management, products, content, devices, and the end user service characteristics, as well as how agile the system is so that it can deal with the evolution of the business and its customers.

What are the challenges faced in SOA adoption?

What are the challenges faced in SOA adoption?

One obvious and common challenge faced is managing services metadata[citation needed]. Service Oriented Architecture SOA-based environments can include many services which exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact is a complicated task.

Another challenge is providing appropriate levels of security. Security model built into an application may no longer be appropriate when the capabilities of the application are exposed as services that can be used by other applications. That is, application-managed security is not the right model for securing services. A number of new technologies and standards are emerging to provide more appropriate models for security in Service Oriented Architecture SOA. See SOA Security entry for more info.

As Service Oriented Architecture SOA and the WS-* specifications are constantly being expanded, updated and refined, there is a shortage of skilled people to work on SOA based systems, including the integration of services and construction of services infrastructure.

Interoperability is another important aspect in the Service Oriented Architecture SOA implementations. The WS-I organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce compatibility. Testing tools have been designed by WS-I to help assess whether web services are conformant with WS-I profile guidelines. Additionally, another Charter has been established to work on the Reliable Secure Profile.

There is significant vendor hype concerning Service Oriented Architecture SOA that can create expectations that may not be fulfilled. Product stacks are still evolving as early adopters test the development and runtime products with real world problems. SOA does not guarantee reduced IT costs, improved systems agility or faster time to market. Successful SOA implementations may realise some or all of these benefits depending on the quality and relevance of the system architecture and design[15] . See also: WS-MetadataExchange OWL-S Abrobit Roy

SOA 2.0 or Advanced SOA

SOA 2.0 or Advanced SOA

Amid much negative reaction, Oracle is taking up Service Oriented Architecture SOA 2.0 as "the next-generation version of SOA" combining service-oriented architecture and Event Driven Architecture, and categorizing the first iteration of SOA as client-server driven[11] . Even though Oracle indicates that Gartner is coining a new term, Gartner analysts indicate that they call this advanced Service Oriented Architecture SOA and it is 'whimsically' referred to as SOA 2.0.[12] Most of the pure-play middleware vendors (e.g., webMethods and TIBCO) have had SOA 2.0 attributes for years. Service Oriented Architecture SOA 2.0 can therefore be regarded as "more marketing noise than anything else"[13] and product evangelism rather than a new "way of doing things".

However, other industry commentators have criticized attaching a version number to an application architecture design approach, while others have stated that the "next generation" should apply to the evolution of SOA techniques from IT optimization to business development

SOA, Web 2.0, and mashups

Service Oriented Architecture SOA, Web 2.0, and mashups

Web 2.0 refers to a "second generation" of web sites, primarily distinguished by the ability of visitors to contribute information for collaboration and sharing. Web 2.0 applications use Web services and may include Ajax, Flash, Silverlight or JavaFX user interfaces, Web syndication, blogs, and wikis. While there are no set standards for Web 2.0, it is characterised by building on the existing web server architecture and using services. Web 2.0 can therefore be regarded as displaying some service oriented architecture SOA characteristics[9].

Mashups are also regarded by some as Web 2.0 applications. The term "enterprise mashup" has been coined to describe Web applications that combine content from more than one source into an integrated experience, which share many of the characteristics of service-oriented business applications (SOBAs), which are applications composed of services in a declarative manner. There is ongoing debate about "the collision of Web 2.0, mashups, and service oriented architecture SOA", with some stating that Web 2.0 applications are a realisation of service oriented architecture SOA composite and business applications.

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture

SOA and Web Service Protocols

Service Oriented Architecture SOA and Web Service Protocols

SOA Service Oriented Architecture may be built on Web services standards (e.g., using SOAP) that have gained broad industry acceptance. These standards (also referred to as web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, implement Service Oriented ArchitectureSOA using any service-based technology, such as Jini.

Service-oriented architecture SOA is often defined as services exposed using the Web Services Protocol Stack[citation needed] . The base level of web services standards relevant to Service Oriented Architecture SOA includes the following:

XML - a markup language for describing data in message payloads in a document format
HTTP (or HTTPS) - request/response protocol between clients and servers used to transfer or convey information
SOAP - a protocol for exchanging XML-based messages over a computer network, normally using HTTP
XACML - a markup language for expressing access control rules and policies.
Web Services Description Language (WSDL) - XML-based service description that describes the public interface, protocol bindings and message formats required to interact with a web service
Universal Description, Discovery, and Integration (UDDI) - An XML-based registry to publish service descriptions (WSDL) and allow their discovery

Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented." For example, some service oriented systems have been implemented using Corba, Jini and REST.

SOA Service-oriented design and development

SOA Service-oriented design and development

The modelling and design methodology for Service Oriented Architecture SOA applications has become known by the terms service-oriented analysis and design and SOAD [8]. SOAD is a design methodology for developing highly-agile systems in a consumer/producer model that abstracts implementation from process, such that a service-provider can be modified or changed without affecting the consumer.

Service contract

A service contract needs to have the following components:

Header
Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
Version - The version of this service contract
Owner - The person/team in charge of the service
RACI
Responsible - The role the person/team is responsible for the deliverables of this contract/service. All versions of the contract
Accountable - Ultimate Decision Maker in terms of this contract/service
Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
Type - This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:
Presentation
Process
Business
Data
Integration
Functional
Functional Requirement (From Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.
Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.
Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for an internal and external clients each with a different invocation means and interface. Examples:
SOAP
REST
Events Triggers
Non-Functional
Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.
Quality of Service - Determines the allowable failure rate
Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?
Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions
Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
Process - Describes the process, if any, of the contracted service

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture
Home: SOA Service Oriented Architecture

SOA principles

SOA Service Oriented Architecture principles

The following guiding principles define the ground rules for development, maintenance, and usage of the Service Oriented Architecture SOA.

Reuse, granularity, modularity, composability, componentization, and interoperability
Compliance to standards (both common and industry-specific)
Services identification and categorization, provisioning and delivery, and monitoring and tracking

The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:

- Service Encapsulation
- Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
- Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
- Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
- Service reusability - Logic is divided into services with the intention of promoting reuse
- Service composability - Collections of services can be coordinated and assembled to form composite services
- Service autonomy – Services have control over the logic they encapsulate
- Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
- Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.

In addition, the following factors should also be taken into account when defining a SOA implementation:

- Service Oriented Architecture SOA Reference Architecture SOA Practitioners Guide Part 2: SOA Reference Architecture covers the SOA Reference Architecture, which provides a worked design of an enterprise-wide Service Oriented Architecture SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.
- Life cycle management Service Oriented Architecture SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key Service Oriented Architecture SOA standards, and recommended links for more information.
- Efficient use of system resources
- Service maturity and performance
- EAI Enterprise Application Integration

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture
Home: SOA Service Oriented Architecture

Why SOA?

Why Services-Oriented Architecture SOA?

The main drivers for Services-Oriented Architecture SOA adoption are that it links computational resources and promotes their reuse. Enterprise architects believe that Services-Oriented Architecture SOA can help businesses respond more quickly and cost-effectively to changing market conditions[5] . This style of architecture promotes reuse at the macro(service) level rather than micro(objects) level. It can also simplify interconnection to - and usage of - existing IT (legacy) assets.

Services-Oriented Architecture SOA Practitioners Guide: Why Services-Oriented Architecture? provides a high-level summary on SOA.

In some respects, SOA Services-Oriented Architecture can be considered an architectural evolution rather than a revolution and captures many of the best practices of previous software architectures. In communications systems, for example, there has been little development of solutions that use truly static bindings to talk to other equipment in the network. By formally embracing a SOA approach, such systems are better positioned to stress the importance of well-defined, highly inter-operable interfaces.[citation needed]

Some have questioned whether Services-Oriented Architecture SOA is just a revival of modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s)[citation needed]. SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximize reuse of services

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture

SOA definitions

Service Oriented Architecture SOA definitions

SOA Service Oriented Architecture is a design for linking business and computational resources (principally organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

There are multiple definitions of Service Oriented Architecture SOA, the OASIS group and the Open Group have created formal definition with depth which can be applied to both the technology and business domains.

Open Group SOA Definition (SOA-Definition)[3]
OASIS SOA Reference Model (SOA-RM)[4]
What Is Service-Oriented Architecture? (XML.com)
What is Service-Oriented Architecture? (Javaworld.com)
Webopedia definition
TechEncyclopedia definition
Object Management Group (OMG ) SOA Special Interest Group definition
WhatIs.com definition
SearchWebServices.com Numerous SOA definitions by industry experts

Though many definitions of Service Oriented Architecture SOA limit themselves to technology or just web services, this is predominantly pushed by technology vendors; in 2003 they talked just of web services, while in 2006 the talk is of events and process engines.

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture