+1. There's just too many people think they are doing SOA when they are just offering technologies such as web service or ESB. No wonder there's so much failure. I met a "SOA consultant" who suggested using web service on a very high volume transaction system. Met another fellow who knew how to create a web service but didn't have any idea about the field of application. Makes me think of a cliche: 1.A hammer is a hammer is a hammer. 2.When you have a hammer, everything looks like a nail.
I'm beginning to think there's more a need for a person to understand the computer basics before SOA. BTW, will be in Orlando this July. Didn't make the other deadline. Setting up to go outside Japan a few more times this year. :-) H.Ozawa --- In [email protected], Anne Thomas Manes <atma...@...> 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 > <gervas.doug...@...> 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 > > >
