|
|
| Service Oriented Enterprise |
|
|
Saturday, May 31, 2003 Girthy Protocol Stacks GXA (A.K.A., WS-*) is creating a girthy protocol stack, that is, the distance around the circumference of the protocol stack seems to grow daily. The girth for the base internet protocol stack was pretty small: UDP, TCP, DNS, etc. - The cohesion within the protocol was high. However, the coupling between the protocols was moderate-to-high. That is, there were a significant number of times when a given protocol called out a "unique binding" rather than calling out "a requirement for a concern". In the world wide web, the girth was minimal: HTTP, URI, HTML, etc. In the world wide grid, the girth seems to be rather large: SOAP, UDDI, WSDL, WS-Inspection, WS-Transaction, WS-Security, WS-ReliableMessaging, etc. Girthy protocols worry me only when they are mandatory. If I can choose the specific protocols that I want to use in the stack, rather than having to accommodate each layer in the stack I have increased flexibility and decreased the problems associated with girthy protocol stacks. Protocols become mandatory when the cohesion between protocols is high. This occurs when a protocol SPECIFIES that you MUST use another specific protocol. This is what I call a "unique binding". It occurs all the time in the web services protocols. Rather than stating that one protocol requires the remedy of some concern (e.g. addressing), the protocol calls out a specification by name. In these cases, we end up creating "protocol frameworks". The creation of protocol frameworks that are bound and versioned via a profile (like WS Basic Profile) may be required given the state of the art of protocol design. However, as we begin to adopt the ws-* stack we must be aware of the cohesion and versioning issues that will arise in the future. posted by jeff | 7:23 AM Friday, May 30, 2003 The World Wide Grid Well, I finally took the time to write down my thoughts on the future of the Web Service Network. I have taken the liberty to give it a name, that is, "The World Wide Grid" or just, "The Grid". I hope you enjoy: http://schneider.blogspot.com/wwg.htm posted by jeff | 6:03 PM Thursday, May 29, 2003 The Client-Side Platform: Part I The Conversation “We just converted the last of our client/server applications to thin-client!” exclaimed a friend of mine at a local Fortune 500 company. “Why?” I asked. “What do you mean why? We changed our architecture to n-tier with application servers and browser interfaces.” To which I could only ask, “Why?” I could see that I was irritating him, but I thought I’d let him hang for a minute. This was a technically adept, well-paid engineer. He commented, “We went to n-tier because we could reduce our deployment costs. All the applications are now delivered to the clients without requiring p.c. administrators to install them! We can also deliver applications to our business partners over the Internet.” “Those are all great things. You must be proud. Did you give up anything to accomplish this feat?” I asked. “No, I don’t think so – what do you mean?” he asked. “Well did you increase your server side costs? Did you deliver the application with the same robust user interface that you had in the client/server world? If I remember correctly, the client/server version used to connect to a bar-code reader on the pc, was that hard to do in HTML?” Now he was aggravated. I had just pointed out three things that were worse in the new system that he preferred not to talk about. Conversations similar to this one are popping up in virtually every Fortune 500 I.T. shop. Why did we compromise on so many items? The answer is simple; the immediate advantages of the browser out-weighed any other solution that was presented at that point in time. The Browser The web browser was designed to enable a simple method for linking information across physical locations and rendering structured documents. These goals were met with overwhelming success. The browser was so successful that people began thinking of it as the sole method of sending and receiving information. Even other traditional applications like email were redesigned for this new model. It was apparent that the software designer could kluge just about any piece of software to work in this paradigm. As time went on, the software community began to realize that stuffing every application into the same architectural model would not adequately serve the needs of the user or the engineer. The intentions behind the web browser were noble. No one could have predicted that an entire generation of developers would have attempted to transition all of their programming needs to this new model. Had they, the browser would surely have a different design. Before the browser we had some pretty powerful features: robust user interfaces, access to local peripherals, client-side computing and storage, etc. Plenty of sophisticated features were traded for the promise of ubiquitous graphical rendering. Well, today we have ubiquitous rendering but none of the other features that developers consistently need at the client. We have tried to remedy this issue but met with limited success. The Java applet failed to achieve significant success due to the limited support in the Microsoft Internet Explorer browser, while the ActiveX control remained ridden with security issues. Clean Sheet of Paper Developers are now re-thinking the role of the browser. What would client-side computing look like if you had a clean sheet of paper? Should it be the primary mechanism for delivering fat client side code? Should it always be a client and never a server? The answer to these vatic questions are leading many to believe that the client may be ready to undergo yet another major transformation. No one is suggesting that we do away with the browser, rather that we use it for what it was originally intended to do, rendering structured documents with hyperlinks. The new goal is to balance a few simple concepts: · I need continued access to my thin-client applications and web sites. Anything that I had in a browser I want to continue to have! · Sometimes I work offline and I should be able to keep working when I’m not connected to the network. · I need to communicate and collaborate with co-workers and business associates, often in real-time. · I don’t want complicated installs nor does my I.T. department want to roll out new applications. · Some personal information I’d like to keep on my computer rather than at a remote server. Client Side Platforms Five years ago I.T. shops were against adding anymore to the client than was absolutely needed. Today, as CPU performance is skyrocketing and disk and memory prices plummeting, there is a less emphasis on the hardware restrictions and a renewed interest in delivering more robust applications to the user. Also, software developer are tired of cursing HTML, trying to make it do things that it was never meant to do. Returning many of the basic features that we had before browsers is the goal of the next generation of client side platforms. The CSP is really not a new concept. The CSP is merely a combination of those technical features that software developers need when writing client-side systems, while stressing strong (yet loose) integration between those components. (more coming soon...) posted by jeff | 7:22 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
