This post originated from an RSS feed registered with Java Buzz
by Bill de hÓra.
Original Post: Steve Vinoski on WS inside the enterprise
Feed Title: Bill de hÓra
Feed URL: http://www.dehora.net/journal/atom.xml
Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8
Most of the people I encounter in my circles, for example, use "web services" to describe intra-enterprise business services that can be accessed over a variety of protocols. These services are not and will never be offered over the WWW. They're not necessarily RESTish. They don't need to scale to web scale, and never will. Some are stateful, some are not. They might in fact be steaming piles of poorly designed and poorly written code, and in fact are often built on what many purists might consider to be obsolete technologies. Regardless, what's most important about them is that they work, and so these businesses want to make them even more valuable by making them much more accessible within their businesses. They're happy to describe these services in WSDL, since that helps them abstract the services, but they don't want to have to redesign them or rewrite them or change their protocols or adopt new unproven approaches just so they can ensure that the services conform to some purist's view of what's a "real web service." - Steve Vinoski Very true. We might call this space Dark-WS. A part of the SOA/WS driven work we do involves placing service facades on top of legacy systems. It's not acceptable for some of these systems to risk breakage through alteration; thus they can't be touched during engagement. One of the great attractions of using Internet protocols and markup is that they induce an integration strategy of "least interference" with existing systems. Compared to something like JCA connectors at least. Often these systems were engineered for batch work and not as servers. The interesting engineering problem focuses not only on the integration but on enabling the existing systems to cater for increasing and variant forms of load. You also have to take operations into account - batch systems tend not to be set up for 24x7 mangement or anything like application level fault notification - often you have people monitoring the job as it runs. For me, one of the trickiest parts in all this is managing the gateway between web and legacy namespaces - we have a pattern called T3 to help us with this, based on asynchronous messaging; I hope to write that up soon :)...
Previous Topic
