SOAs offer a flexible, extensible and composable approach to reusing and extending existing applications and constructing new ones.
Services advertise capabilities, both offered and requested, by declaring interfaces they implement or expect other services to implement, and by declaring policies governing potential partner interactions. Web Services Description Language (WSDL) and other Web services standards, such as WS-Policy, provide the vocabulary for these declarations. (See <http://www.ibm.com/developerworks/library/ws-soa-progmodel4/#resources>the WSDL, Version 2.0 Part 0: Primer.) *Virtualization of business functions, a key goal of an SOA*, is achieved by isolating service definition and usage from service implementation. Services may be implemented using a wide range of technologies, including IBM WebSphere MQ, IBM CICS or IBM IMS, Java 2 Platform, Enterprise Edition (J2EE) Enterprise JavaBeans (EJB), Java classes, IBM DB2 Queries, Java Message Services (JMS), or Microsoft .NET. Service requesters dispatch requests to a service provider that offers the capabilities they desire, unaware of its implementation. An ESB is an architectural pattern that supports virtualization and management of service interactions between communicating participants. It provides connectivity among service providers and requester, facilitating their interactions even if they are not exactly matched. This pattern can be implemented using a variety of middle ware technologies and programming models. If such middle ware technologies and/or programming models are not compatible then there is no way to access the services without implementing such technologies or middle ware on both sides. What Jerry WaldorfJerry Waldorf and Ashesh Badani addressed, is practically right. In addition, ESB could be used with any EAI as well as with SOA. SOA has the philosophy to expose the endpoints as equal and free members of the IT landscape. Each endpoint is visible and addressable. Endpoints can enforce security or transactions by providing a policy containing corresponding assertions. A very promising specification for the endpoints is WS-Addressing<http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/>. All the best Ashraf Galal On Sun, May 24, 2009 at 6:48 PM, Anne Thomas Manes <[email protected]>wrote: > > > Okay -- this definitely does not qualify as a good SOA practice. It > sounds like traditional EAI. I guess that's what you should expect > from the See Beyond guys. Any ESB should enable the department manager > to access the customer information "service" without installing a > specific vendor's middleware. > > > > For example, a department manager who wants access to > > customer information from another business unit may find that the data is > > housed in a proprietary middleware bus. In this case, the only way she > can > > access it is by installing the same middleware on her servers, training > > staff to manage the software, and paying the vendor fees to maintain it. > > I'm a huge proponent of exposing service via URLs and HTTP, but this > article starts off with a bogus thesis. > > Anne > > > On Sun, May 24, 2009 at 5:11 PM, Gervas Douglas > <[email protected] <gervas.douglas%40gmail.com>> wrote: > > <<As consumers we are accustomed to the end-user experience of the > Internet. > > With HTTP and XML, you don't need to have a specific application on your > > computer to make use of external data - you can just open a browser > window > > and do a search or visit a particular Web site to find the information > you > > need. > > > > But inside an enterprise, sharing data and applications is far more > complex. > > Enterprise SOA vendors have added advanced tools and enabled capabilities > > that leverage complex specs, making it more difficult for smaller > projects > > to use these features. Although the software may be based on open > standards, > > it often requires a thorough understanding of a range of standards to > > integrate the data. For example, a department manager who wants access to > > customer information from another business unit may find that the data is > > housed in a proprietary middleware bus. In this case, the only way she > can > > access it is by installing the same middleware on her servers, training > > staff to manage the software, and paying the vendor fees to maintain it. > > > > These kinds of obstacles don't exist on the Internet, where you can go to > > sites like Google Maps, create a mashup, and send it to your contacts > > through Facebook. If you want data, you can go directly to the source via > > open APIs and use it as you see fit. That same capability is needed in > the > > enterprise. For example, Web Services developers must choose between > using a > > RESTful architecture, which has some limitations regarding security, or > > traditional Web Services (WS) standards, which provide heavy security but > > are more complex to deploy. And if a developer adds single sign-on > > functionality to a RESTful interface, the complexity grows. > > > > What we need for the enterprise - and where we believe SOA is heading - > is > > an interface that allows someone to interact directly with data through > > standard protocols and simple access management instead of through a > > heavyweight platform, as well as the ability to select the right tool for > > the job - Web Services where appropriate and a RESTful approach when > > required. > > > > Advantages in Going Lighter > > By not requiring departments to use a specific enterprise stack for > > everything they do, productivity can improve considerably. For example, > if > > an employee in another division located in another country needs access > to > > data on another department's system, he should be able to do an HTTP GET > (as > > long as he has the right access control) to retrieve the data he needs in > an > > XML document. > > > > On the developer side, the requirement to federate more and more > > applications and data across traditional corporate boundaries - and at > the > > same time deliver those new services quickly - already has enterprise IT > > departments looking for new options. For instance, a project team that is > > tasked with developing five new services that are to be tested and > deployed > > in two months may find that the complexities of the organization's > > enterprise platform make it impossible to meet their deadline. If they > had a > > framework that includes data services and identity management, they would > be > > able to cut time to market substantially and make that deadline. > > > > Because faster time-to-market is becoming the overriding criteria for > > successful application infrastructure projects, SOA frameworks of the > future > > will need to deliver more application infrastructure capabilities in less > > time - and without unnecessary complexity. > > > > Looking to the Internet > > Metadata discovery would also need to be a key part of such a lightweight > > framework. Many SOA platforms have evolved to include heavyweight > > repositories for service definitions, which require the service > definitions > > to be separated from the implementations and placed in large registries. > One > > lesson we can learn from the Internet is the benefit of lightweight > indices; > > for example, Google and Yahoo! allow for searching across all of the > sources > > of information without consolidating that information into a single > > location. We search for information and we are then directed to the > source > > of that information for the latest version. This same structure can be > > applied to service registries; we can employ a lightweight index of > service > > locations that points us to the actual implementations of those services. > > > > Metadata is still important; we just need to handle it in a more > lightweight > > manner. The metadata about what a service offers (what data it presents > and > > what data it expects) will have to be located with the implementation of > the > > service so the data doesn't get out of sync. Lightweight conventions like > > WSDL or WADL could be employed to package the metadata along with the > > resource implementation. And putting all of these locations into a single > > searchable lightweight index would provide just the right level of > > centralization without slowing down the innovation. However, there is > still > > some work that needs to be done in this area to promote lightweight > > standards to address metadata packaging in REST resources. > > > > Leveraging Clouds > > Looking ahead, more and more Web Services will be built for and leveraged > > from a cloud. Enterprise developers will need a framework that enables > them > > to create secure Web Services that can be accessed via the Internet or > the > > cloud. A lightweight service that is deployed in a way that external > parties > > can access it has to provide access control that depends on external > > identity. This is where identity architectures need to scale out to a > global > > perspective. Some WS-* protocols are targeted at providing a solution for > > this. However, there's additional work that needs to be done to allow a > > simplified external identity model to be applied to the REST-style > > programming model. New identity architectures will need to be defined to > > secure REST resources for programmatic consumption, just as initiatives > like > > OpenID have done to simplify human-based externalized identity. > > > > Enterprises may also choose to develop and house some applications that > > provide a competitive advantage internally and house other less > > mission-critical applications on an external cloud. And, both categories > > will need to interoperate. For example, a company may use Salesforce.com > but > > need it to interact with customer information located in an internal > Oracle > > or SAP application. A unified security programming model for RESTful > > resource exposure can provide the developer a consistent way to access > > resources - regardless of where the resource comes from (inside the > > corporation or outside). A lightweight security model that can be used > both > > inside and outside the corporation would help in this process. > > > > Currently every SaaS interface has a different non-standard way of > > controlling access to resources; this makes what could be a simple mashup > > problem difficult. Combining the data together from multiple sources is > the > > easy part, but getting all of the right credentials together for > accessing > > all of the disparate resources is tricky. > > > > Identity Management Critical > > As developers create Web Services that provide access to data to an > > ever-expanding federated audience, identity management is critical. When > > users present credentials to access a Web Service, there must be > validation > > that they're part of a larger system that allows them to access what > they're > > requesting - just like when you present a debit card to make a purchase > or > > get a cash advance at the grocery store. If you could only use that card > at > > ATM machines run by the credit card issuer, that would be a heavyweight > > model; a non-distributed security model. Instead, the card issuer enables > > you to use the card virtually anywhere, assuring the store of your > security > > credentials to do the transaction. > > > > Similarly, such a distributed model for Web Services enables developers > to > > create greater value by emphasizing the service and not verification of > > security credentials. While an identity management function doesn't have > to > > be embedded in the offering, the Web Service needs to be able to connect > > with identity management software through lightweight standards; this > > enables developers to focus on the service offering. > > > > Greater Mobility > > Finally, with the increasing need for Web Services to run on a variety of > > screens - desktop, laptop, mobile devices, and set-top boxes - Web > Services > > developers need an application infrastructure that is simple enough to > > accommodate all of those possibilities. The emphasis is on quick access > to > > data and multiple fast reads from a database table with greater > intelligence > > on the edge. Where enterprise-class applications that offer all the > > "-ilities" were the focus in the past, lightweight, Web-scale > applications > > that can be used on a range of screens - particularly on mobile devices - > > will continue to grown in dominance. > > > > For example, the iPhone or Blackberry could become a next-generation > > publishing platform, or perhaps provide contextual intelligence that > offers > > highly targeted location-based advertising or other information relevant > to > > appropriate potential customers. But to create such services, developers > > must be able to easily leverage data services and identity management > > capabilities; a lightweight framework that provides both would be ideal. > > > > Demand for Simpler Framework Will Be Addressed > > To enable enterprises to meet the ever-growing demand to deliver new > secure > > Web Services and quickly and easily leverage data across the business, a > > simpler SOA framework specifically designed for smaller projects is > needed. > > > > Web scale is the new enterprise class that organizations will all aspire > to. > > As work continues in developing and promoting lightweight standards, we > > believe that enterprise developers will soon have a simpler platform that > > helps them significantly speed and simplify Web Service design and > > deployment.>> > > > > You can read this at: http://in.sys-con.com/node/973243 > > > > Gervas > > > >
