|
|
| Service Oriented Enterprise |
|
|
Thursday, March 04, 2004 The Web Service Dial Tone Web Services are failing and I know why. Most people I talk to think the lack of adoption is for one of two reasons: 1. The huge WS-* stack is too complicated and it reminds them of CORBA. 2. We haven't found a killer app for ws. These are both interesting - but in my opinion, they are not the real reason why ws are failing. I firmly believe the answer is very simple; we haven't created a web services dial tone. When I plug my laptop into a network, it immediately sends a broadcast message to the network. Certain devices like routers, firewalls, gateways, etc. respond to the inquiry and pass on some information about their capability and service offerings. This transparent conversation creates a 'network dialtone' - it enables a device to plug into a network, discover the services and converse with them. This capability is at the heart of our TCP networks, but has not been realized in our 'web service networks'. In order to create a ws-dialtone we need only a handful of capabilities. 1. Consumer-side applications need the ability to send a broadcast message to a network (UDP for web services). 2. Producer-side applications need to be able to listen to the broadcast and respond. They also need the capability to broadcast their availability. 3. UDP style broadcasts are limited to a sub-net. Thus, sub-net routing (via a soap router) is critical. Much of this functionality is available via the WS-Discovery specification. However, a large number of people in the ws community view the aforementioned protocol as a tool to be used strictly in ad-hoc networks or for consumer hardware devices. And although this is a subset of the target audience, it has broader applicability in the enterprise environment. As we continue our movement towards contract based development we will begin to see more emphasis on standardizing the contract. Today, our standardized contracts come in the form a platform like J2EE (technical contracts) or from industry working groups (business contracts). The combination of the standardized contract, the discoverable implementation and late binding will introduce a computing model that enables a service oriented system to automatically find producers for a predetermined piece of functionality and to bind to it. Imagine installing a workflow system and immediately after installation, the server found all of the other dependent services (LDAP, single sign-on, etc.) and registered the bindings to those services. This is the vision of a service oriented enterprise - it focuses on the simplified integration of systems by using ubiquitous protocols, standardized contracts and late binding on a dial tone network. posted by jeff | 8:47 AM Tuesday, March 02, 2004 Whitehorse & Virtualization Microsoft has been touting a next generation designer for creating services and then facilitating the deployment of the services. As Microsoft puts it: "When creating mission-critical software, application architects often find themselves communicating with their counterparts who manage data center operations. In the process of delivering a final solution, the application's logical design is often found to be at odds with the actual capabilities of the deployment environment. Typically, this communication breakdown results in lost productivity as architects and operations managers reconcile an application's capabilities with a data center's realities. In Visual Studio Whidbey, Microsoft will mitigate these differences by offering a logical infrastructure designer (Figure 19) that will enable operations managers to specify their logical infrastructure and architects to verify that their application will work within the specified deployment constraints." The environment allows you to drag a service description to a physical node and drop it on the node to signify deployment.  At first this seemed like a great idea, but after spending some time with the IBM grid team they quickly reminded me that "services belong to the network, not a predefined physical node". Thus, hardcoding service locations to a physical node kills the benefit of virtualization. Well - I agree - you want to drag your service to a "service network" and there should be various sub-nets that are partitioned based on resources and capability. But, I must admit... the Whitehorse demo sure looks cool... It is very "Microsoft". posted by jeff | 2:24 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
