If you ever get into a conversation which discusses use cases of SOA, then you have probably heard of the Purchase Order (PO). The use case goes something like this, there is a PO which needs to be routed across multiple enterprise components (recently exposed as web services) and this PO needs to find its way to its destination through a maze of business processes. It seems every one has a policy which says "if the PO is greater than some dollars then send it to big boss otherwise the little guy can do it as well".
So abstracting the use case out a bit, we are saying the PO is the input into a black box and some processing occurs and the PO changes the state of the black box and returns a zero or more messages saying so to the originator.
I have yet to hear someone question this use case in context of the vision of SOA enabled datacenter. I always wonder why the PO even has to even exist. After all in the world of SOA, multiple systems are now connected at the application level and supposedly understand the business processes extant in the organization.
POs were created because the buyer and seller had no other way to account for a transaction. PO was the document that implemented the approval process, the actual transaction and the budgeting process. If the underlying IT infrastructure is moving towards loose coupling, the overlaying business processes would need to be reengineered to take advantage of this new infrastructure.
I think the biggest opportunity in SOA might end up in the laps of management consultants. Perhaps, I should have stayed at Booz.Allen ;)
Thursday, February 09, 2006
SOA Patterns and AON Appliances
There is a lot of discussion around SOA patterns now-a-days. If you have used patterns in your past life, these SOA patterns are not really the same thing. It is not a reusable chunk of code that you can cut & paste. These are big chunks of functionality that needs to be deployed at various points in your network. From an AON perspective, almost every pattern in SOA can become an independent appliance on the network.
When the first appliances hit the market in 1997 timeframe, the pattern they followed was Linux + some server. An AON appliance is a dual plane appliance which has XML for data plane and a control plane which depending upon the pattern that the AON appliance is implementing can be Java or a scripting language or anything else. The performance of course comes from the data plane.
So if we survey the SOA landscape today, we can easily find references to Gateway Pattern, Governance Pattern, Broker Pattern, Router Pattern etc. Each one of these can be made into an appliance in a service oriented network. The only difference between the appliances would be the control plane. You could deploy all these patterns into a collective which some folks call the ESB or you could drop-in appliances at various points in the network to achieve the same result.
Once you have the patterns deployed the challenge shifts to managing the multiple deployed patterns, plan for capacity, scale it and secure it etc. This is where a network based approach with appliances shows its clear advantage. Capacity planning, securing, scaling, sharing etc. are networking's forte.
When the first appliances hit the market in 1997 timeframe, the pattern they followed was Linux + some server. An AON appliance is a dual plane appliance which has XML for data plane and a control plane which depending upon the pattern that the AON appliance is implementing can be Java or a scripting language or anything else. The performance of course comes from the data plane.
So if we survey the SOA landscape today, we can easily find references to Gateway Pattern, Governance Pattern, Broker Pattern, Router Pattern etc. Each one of these can be made into an appliance in a service oriented network. The only difference between the appliances would be the control plane. You could deploy all these patterns into a collective which some folks call the ESB or you could drop-in appliances at various points in the network to achieve the same result.
Once you have the patterns deployed the challenge shifts to managing the multiple deployed patterns, plan for capacity, scale it and secure it etc. This is where a network based approach with appliances shows its clear advantage. Capacity planning, securing, scaling, sharing etc. are networking's forte.
Wednesday, January 04, 2006
AON Device Programming
The fireside chat from a Cisco executive on SONA addresses a FAQ on AON devices's programming environment. If you have the time, I assure you this 1 hr+ presentation is worth the time.
As the presenter points out, AON devices are not programmed in the same way as the server side cousins. There is no IDE, SDK or APIs. The fundamental task of an AON device is to find the destination service and route the message to that service and perform any intermediary tasks that can be in done in the network. This message path is programmed rather differently than a server side implementation. For example, a message path which simply accepts a message from a synchronous http channel and dispatches that message to an SMTP channel would look like this.
[from-http-sync]
Match => "SomePatternInAnyGrammar", WithThisPriority#, RunSomeProcessing
Catch => "ForTheSamePattern", ThisException, RunThisExceptionHandler
Include => SomeOtherContext, WithTheseConditions
Dispatch (TransformedMessage, OnThisChannel)
These simple context can be combined to form a larger context which defines the message path. On the CLI one can easily verify that this rule is turned on by
CLI> show context from-http-sync
[from-http-sync created by ...]
'Pattern'
1. SomeProcessing
2. Included Processing steps of another context
3. Dispatch to SMTP
As the presenter points out, AON devices are not programmed in the same way as the server side cousins. There is no IDE, SDK or APIs. The fundamental task of an AON device is to find the destination service and route the message to that service and perform any intermediary tasks that can be in done in the network. This message path is programmed rather differently than a server side implementation. For example, a message path which simply accepts a message from a synchronous http channel and dispatches that message to an SMTP channel would look like this.
[from-http-sync]
Match => "SomePatternInAnyGrammar", WithThisPriority#, RunSomeProcessing
Catch => "ForTheSamePattern", ThisException, RunThisExceptionHandler
Include => SomeOtherContext, WithTheseConditions
Dispatch (TransformedMessage, OnThisChannel)
These simple context can be combined to form a larger context which defines the message path. On the CLI one can easily verify that this rule is turned on by
CLI> show context from-http-sync
[from-http-sync created by ...]
'Pattern'
1. SomeProcessing
2. Included Processing steps of another context
3. Dispatch to SMTP
Wednesday, December 21, 2005
AON Devices - Server Appliances or Network Appliances
Ever since Cisco announced its AON and now SONA strategy, every SOA appliance vendor has embraced the TLA "AON". The definition of AON however is still as ambiguous as its server side counterpart ESB. IMHO, the answer lies in answering the question "Are AON devices server appliances or network appliances? "
A server appliances is a network attached closed server that performs one function i.e. offload the server. All the devices from SOA appliance vendors available today do exactly this. They offload security processing from the server. Some of the ambitious ones will offload business process orchestration from the server. All of this is to optimize the performance of an application that adhers to SOA principles. A server appliance is sold to a server system administrator.
A network appliance is a "in-line" network device. It does not offload processing from a server. It simply redirects, routes application flows to servers which are attached to the network. This routing is based on metadata that is part of the payload. This single function differentiates it from a standard router which only looks at packet level information to route a flow. Using a network appliance, one can create a VLAN which is SOAP 1.1 only. One could create a load balancer which distributes load based on transaction identity and not just sessions. A network appliance is sold to a network manager.
I have heard folks say network managers are not knowlegeable about SOA and its protocols of communication. Well, they were not aware of HTTP and web protocols in 1995. But they are well versed in it now. The reason these folks are not interested in talking to vendors, is vendors keep taking a server appliance to them and try to sell that as if it were a network appliance.
A server appliances is a network attached closed server that performs one function i.e. offload the server. All the devices from SOA appliance vendors available today do exactly this. They offload security processing from the server. Some of the ambitious ones will offload business process orchestration from the server. All of this is to optimize the performance of an application that adhers to SOA principles. A server appliance is sold to a server system administrator.
A network appliance is a "in-line" network device. It does not offload processing from a server. It simply redirects, routes application flows to servers which are attached to the network. This routing is based on metadata that is part of the payload. This single function differentiates it from a standard router which only looks at packet level information to route a flow. Using a network appliance, one can create a VLAN which is SOAP 1.1 only. One could create a load balancer which distributes load based on transaction identity and not just sessions. A network appliance is sold to a network manager.
I have heard folks say network managers are not knowlegeable about SOA and its protocols of communication. Well, they were not aware of HTTP and web protocols in 1995. But they are well versed in it now. The reason these folks are not interested in talking to vendors, is vendors keep taking a server appliance to them and try to sell that as if it were a network appliance.
Friday, December 16, 2005
Cisco's SONA
Cisco announced its SONA (Service Oriented Network Architecture) www.cisco.com/application/pdf/en/us/ guest/netsol/ns477/c643/cdccont_0900aecd8039b324.pdf.
When implemented correctly, a SONA like architecture will allow an administrator to login into a network services router and run "show http peers" which will list all the web services that are exposed using http binding in the network. Replace "http" with your favorite protocol and you should be able to see web services exposed on your favorite binding. If you type "show some_peer_webservice", you should be able to see its various bindings, its "EPR", its grouping and almost everything you get from WSDL of the service (without the annoying angle brackets).
Moving web services network management away from developers into the hands of operations personnel is the true promise of SOA and SONA delivers on that promise better than any application server centric (open or otherwise) service bus.
When implemented correctly, a SONA like architecture will allow an administrator to login into a network services router and run "show http peers" which will list all the web services that are exposed using http binding in the network. Replace "http" with your favorite protocol and you should be able to see web services exposed on your favorite binding. If you type "show some_peer_webservice", you should be able to see its various bindings, its "EPR", its grouping and almost everything you get from WSDL of the service (without the annoying angle brackets).
Moving web services network management away from developers into the hands of operations personnel is the true promise of SOA and SONA delivers on that promise better than any application server centric (open or otherwise) service bus.
Wednesday, June 01, 2005
Development vs. Deployment
The industry has spent the last five years or so to get a conceptual, architectural buy-in for web-services. The standards related to web services, generally referred to as WS-*, too have gone beyond proprietary workshops to standard bodies' technical commitees. Surprisingly all of this effort was driven by developers, for developers and of developers.
Web Services have a reached a point where if they don't cross over from the developer domain to deployment domain, there is a very real chance that this whole effort will be for nothing.
A key stumbling block towards deployment of web services is lack of real products which embody the technology developed in standards and employ the principles behind web services. While every vendor has a web services marketing program, very few have real web services products. No wonder the few customers who had the resources and implemented web services as pilots are being claimed as the reference customers by every major vendor.
ESB vs. Application Networks
The article by Dave Chappel provides a good description of what ESB is and its roadmap. However there is one critical architectural flaw in ESB. In trying to scale ESB, one has to scale the container. This is very difficult task as we all know from trying to scale other industry standard containers such as J2EE.
IMHO, application networks are better choice for scalable services that ESB offers. The reason is that in a network it is not the control but the data path that is scaled. From networking, we know scaling a data path is far easier than scaling a control. A highly scalable data path with distributed control across the service network can provide all the services of an ESB without the concomittant headaches for IT of having to integrate another layer of middleware on top of already difficult middleware landscape.
IMHO, application networks are better choice for scalable services that ESB offers. The reason is that in a network it is not the control but the data path that is scaled. From networking, we know scaling a data path is far easier than scaling a control. A highly scalable data path with distributed control across the service network can provide all the services of an ESB without the concomittant headaches for IT of having to integrate another layer of middleware on top of already difficult middleware landscape.
Monday, April 25, 2005
Application Networks
There is a lot of buzz on application networks where applications are stitched together using the functionalities exposed by today's large enterprise systems as web services. Before we start to dream about such application networks we may want to put on our systems engineering hats and ask if we even have the underlying infrastructure to support such networks.
Starting at the lowest layer which is all about computing horsepower and storage capacity. With all the efforts around virtualization and on demand everything, we still don't have a compute or storage grid on which such applications can run.
While Grids find their afficionados in the distributed computing field, the Grid as such is more a network related field. In fact, Grid computing is about decomposing a compute problem into a networking problem. This brings us to the next higher level layer in application networks i.e. the messaging fabric. There is no such thing today. All we have today is a few isolated bridges and routers in the form of MOM middleware but nothing that can remotely be classified as infrastructure.
The top two layers in the application networks deal with business logic and processes respectively. IMHO, these are the easiest of the layers to build as they are the most application specific.
Starting at the lowest layer which is all about computing horsepower and storage capacity. With all the efforts around virtualization and on demand everything, we still don't have a compute or storage grid on which such applications can run.
While Grids find their afficionados in the distributed computing field, the Grid as such is more a network related field. In fact, Grid computing is about decomposing a compute problem into a networking problem. This brings us to the next higher level layer in application networks i.e. the messaging fabric. There is no such thing today. All we have today is a few isolated bridges and routers in the form of MOM middleware but nothing that can remotely be classified as infrastructure.
The top two layers in the application networks deal with business logic and processes respectively. IMHO, these are the easiest of the layers to build as they are the most application specific.
Wednesday, January 26, 2005
MTOM/XOP/RRSHB
Finally these specs are done. For those unware of these specs, there is a good intro in this article.
The key questions for me remains if these specs finally enable code mobility across the network?
Code mobility is a big requirement in the embedded devices from switches to PDAs. It is also one of the key services that should be offered by a Grid.
The key questions for me remains if these specs finally enable code mobility across the network?
Code mobility is a big requirement in the embedded devices from switches to PDAs. It is also one of the key services that should be offered by a Grid.
Monday, January 24, 2005
Cisco Getting Into Web Services
Looks like Cisco is getting into web services and middleware.
This is not surprising at all. Just look at the history of Cisco and networking. Everytime the transfer syntax was standardized at a layer in the OSI stack the functionality of that layer migrated out of the server and into appliances like switches. XML and SOAP help standardize the transfer syntax at L6/L7 and now we should see a network at these levels as well.
The ramifications of having a network at these levels is quite profound.
We have to get used to new vocabulary like application overlay networks or service oriented networks. On these networks one can resolve among two components of an application and provide differentiated services to those components just like today's network resolves among two IP addresses and offers differentiated services to each. (Hopefully the guys defining the WS-Addressing specification are reading this).
Instead of a synchronous API call, a developer simply sends an asynchronous message. This message has to traverse a path across heterogenous systems, multiple transports and now-a-days multiple brokers as well. For this to work we would need switches/routers that offer a fast path based on middleware based control.
Applications themselves have to be choreographed instead of developed-- just like today's business process.
The guy who wrote the HBR article "Does IT matter?" is going to be quoted like IBM's CEO who said the world only need two or three of his mainframe computers ;)
This is not surprising at all. Just look at the history of Cisco and networking. Everytime the transfer syntax was standardized at a layer in the OSI stack the functionality of that layer migrated out of the server and into appliances like switches. XML and SOAP help standardize the transfer syntax at L6/L7 and now we should see a network at these levels as well.
The ramifications of having a network at these levels is quite profound.
We have to get used to new vocabulary like application overlay networks or service oriented networks. On these networks one can resolve among two components of an application and provide differentiated services to those components just like today's network resolves among two IP addresses and offers differentiated services to each. (Hopefully the guys defining the WS-Addressing specification are reading this).
Instead of a synchronous API call, a developer simply sends an asynchronous message. This message has to traverse a path across heterogenous systems, multiple transports and now-a-days multiple brokers as well. For this to work we would need switches/routers that offer a fast path based on middleware based control.
Applications themselves have to be choreographed instead of developed-- just like today's business process.
The guy who wrote the HBR article "Does IT matter?" is going to be quoted like IBM's CEO who said the world only need two or three of his mainframe computers ;)
Friday, January 21, 2005
An interesting article on web services standards that you can find here
Computer Magazine - Are Web Services Finally Ready to Deliver?
An interesting quote in that article is that web services' developers are not aware of which standards (defined by W3C/Oasis for interoperability) they are likely to support. Ironically, the whole point of web services is to remove the dependence of interoperability on software coding habits. So it is a good thing that the developers don't know!
The interoperability of components needs to be configured at deployment time not development time. Most of the business code today is written on some sort of container abstraction. It is the responsibility of the container to ensure interoperability of the code that it manages not the developer.
Now who hosts those containers is another debate. Today containers are hosted on some OS running on a GPS. Perhaps it is time to migrate these containers into some fabric which takes care of these low level details and offers fabric wide management functionality.
Computer Magazine - Are Web Services Finally Ready to Deliver?
An interesting quote in that article is that web services' developers are not aware of which standards (defined by W3C/Oasis for interoperability) they are likely to support. Ironically, the whole point of web services is to remove the dependence of interoperability on software coding habits. So it is a good thing that the developers don't know!
The interoperability of components needs to be configured at deployment time not development time. Most of the business code today is written on some sort of container abstraction. It is the responsibility of the container to ensure interoperability of the code that it manages not the developer.
Now who hosts those containers is another debate. Today containers are hosted on some OS running on a GPS. Perhaps it is time to migrate these containers into some fabric which takes care of these low level details and offers fabric wide management functionality.
Wednesday, January 19, 2005
REST Debate
Anybody involved in web services is probably super familiar with the REST debate and probably figured out how to write the filters to filter out the emails to an appropriate folder for offline reading.
From a for-profit product company this debate adds absolutely no value. Customers are essentially resolving this dispute through their use cases. Having spoken to multiple of them albeit from one vertical it looks like the field is using XML over HTTP for presentation traffic (to and fro from a browser) and SOAP over HTTP or JMS for application to application traffic.
So if your product is anywhere close to the tier-1 of the datacenter be prepared for lots of XML coming down your HTTP pipe. If you device is in the second or third tier of the datacenter (like an app server for example), be prepared for majority of the traffic being SOAP.
From a for-profit product company this debate adds absolutely no value. Customers are essentially resolving this dispute through their use cases. Having spoken to multiple of them albeit from one vertical it looks like the field is using XML over HTTP for presentation traffic (to and fro from a browser) and SOAP over HTTP or JMS for application to application traffic.
So if your product is anywhere close to the tier-1 of the datacenter be prepared for lots of XML coming down your HTTP pipe. If you device is in the second or third tier of the datacenter (like an app server for example), be prepared for majority of the traffic being SOAP.
Monday, January 17, 2005
Adaptive Systems Salient Features
Building a building block in the next generation adaptive enterprise is not easy to say the least. The most difficult part is not the complex mechanisms that constitute an adaptive system but the complex communication patterns that emerge that need to be controlled.
So I thought it would be a good idea to put together a list of salient features of any adaptive systems. Here they are..
1) Hierarchies: In any complex system, there is bound to be an hierarchy or multiple hierarchies. To make things even more difficult to implement, these hierarchies are based on loosely coupled entities which join/leave the network as and when they please. The biggest issue of this characteristic is in finding the best addressing scheme.
2) Aggregation: Aggregation or grouping is another characteristic. These groups are short lived or long lived and can form dynamically. Their boundaries need to be represented syntactically in the system and access in and out of this boundary needs to be controlled.
3) Communication: The foundation of any adaptive system lies in it's communication substrate. Communication in such systems is generally a conversation rather than a fire & forget type asynchronous communication or block & timeout type sychronous one.
4) Control: Control is the method to the madness. Unlike conventional systems, however, the control is not static and hardwired but dynamic and mostly embedded in the interaction.
5) Non-Linear Behavior: Unlike your SNMP type faults, faults in such a system cascade into really big blackouts. Fault control mechanisms are there not your traditional "call home or email admin" mechanism but more like circuit breakers. The ability to counter a cascading fault is the true gauge to robustness. It is not about 5 nines and MTBFs.
6) Finally, separation of form from function. I believe I blogged on this when I first started on this project.
Ok, now to implement such a system what has computer science given us? Well, so far just two concepts (a) abstraction (b) virtualization.
So I thought it would be a good idea to put together a list of salient features of any adaptive systems. Here they are..
1) Hierarchies: In any complex system, there is bound to be an hierarchy or multiple hierarchies. To make things even more difficult to implement, these hierarchies are based on loosely coupled entities which join/leave the network as and when they please. The biggest issue of this characteristic is in finding the best addressing scheme.
2) Aggregation: Aggregation or grouping is another characteristic. These groups are short lived or long lived and can form dynamically. Their boundaries need to be represented syntactically in the system and access in and out of this boundary needs to be controlled.
3) Communication: The foundation of any adaptive system lies in it's communication substrate. Communication in such systems is generally a conversation rather than a fire & forget type asynchronous communication or block & timeout type sychronous one.
4) Control: Control is the method to the madness. Unlike conventional systems, however, the control is not static and hardwired but dynamic and mostly embedded in the interaction.
5) Non-Linear Behavior: Unlike your SNMP type faults, faults in such a system cascade into really big blackouts. Fault control mechanisms are there not your traditional "call home or email admin" mechanism but more like circuit breakers. The ability to counter a cascading fault is the true gauge to robustness. It is not about 5 nines and MTBFs.
6) Finally, separation of form from function. I believe I blogged on this when I first started on this project.
Ok, now to implement such a system what has computer science given us? Well, so far just two concepts (a) abstraction (b) virtualization.
Wednesday, September 29, 2004
SOA Network
The article discusses the requirements for the underlying network for SOA to function according to it's claims. While the author has mostly borrowed from existing white papers, there are a few nuggets of gold in there. Here are my thoughts on a few points the author made.
...."An SOA is a business process-driven application integration architecture in which all functions, activities and actions are defined as services and use standards-based interfaces."
This gets to the core of what a SOA network is all about. Business processes are driven by events and the SOA network likewise has to be driven by events and not just traffic patterns and traffic engineering as is today's network. Pub/Sub event distribution model is more suitable for a small installation but for any size of installation worthy of the name "network", this model is not totally not suitable.
The missing link in today's network's readines for SOA is scalable event propagation to entities on the network and the ability to resolve among those entities. Once this is done, the bit about securely and reliably sending messages is straight forward processing and thanks for web service enabled standards, quite interoperable.
.... "But in the end, the SOA's business benefits will outweigh the cost of implementation. "
Amen to that.
...."An SOA is a business process-driven application integration architecture in which all functions, activities and actions are defined as services and use standards-based interfaces."
This gets to the core of what a SOA network is all about. Business processes are driven by events and the SOA network likewise has to be driven by events and not just traffic patterns and traffic engineering as is today's network. Pub/Sub event distribution model is more suitable for a small installation but for any size of installation worthy of the name "network", this model is not totally not suitable.
The missing link in today's network's readines for SOA is scalable event propagation to entities on the network and the ability to resolve among those entities. Once this is done, the bit about securely and reliably sending messages is straight forward processing and thanks for web service enabled standards, quite interoperable.
.... "But in the end, the SOA's business benefits will outweigh the cost of implementation. "
Amen to that.
Saturday, September 25, 2004
Application Networks
The PSTN is the world largest network dedicated to one application i.e. telephony. It works really well, has great QoS and costs a few cents/minute. It has a great business model that supports around $800B dollar industry and employs a few million people around the world.
Look at another network the internet. Supports millions of applications none of which have any QoS, costs a bundle, Does not have a business model that works and employs well in tens of thousands.
Is something wrong here?
Look at another network the internet. Supports millions of applications none of which have any QoS, costs a bundle, Does not have a business model that works and employs well in tens of thousands.
Is something wrong here?
Wednesday, August 11, 2004
Role of the App Server
Somebody ones wrote "To design is to fit form into a context". Of course, here is the valley, we have been fitting "form into a function".
In the web services world, while designing the SOA, we are ones again fitting a form into a function instead of the context. The context of application servers was just that "Servers". The context of SOA is not a server, but the network. Ones vendors realize that we will actually have an SOA solution that does not cost a arm and a leg.
In the web services world, while designing the SOA, we are ones again fitting a form into a function instead of the context. The context of application servers was just that "Servers". The context of SOA is not a server, but the network. Ones vendors realize that we will actually have an SOA solution that does not cost a arm and a leg.
Saturday, July 31, 2004
Don't use Redhat Enterprise Linux, Use Fedora
This new RHEL from Redhat is a pretty much as proprietary as Window XP.
I can't seem to find any binary packages around and after doing research, I found there are none available like they used to be RH 9.0. Yes, they have SRPMs available, but who wants to compile everything from glibc to libGL. Even Microsoft gives the compiled versions of the libraries for free, no so with Redhat. h
Looks like Fedora is the real open source Redhat OS. Use Fedora!
I can't seem to find any binary packages around and after doing research, I found there are none available like they used to be RH 9.0. Yes, they have SRPMs available, but who wants to compile everything from glibc to libGL. Even Microsoft gives the compiled versions of the libraries for free, no so with Redhat. h
Looks like Fedora is the real open source Redhat OS. Use Fedora!
Wednesday, May 05, 2004
Time for Java OS?
Imagine if code was written an appropriate level of abstraction such that it contained no platform dependencies. In such an scenario, the code could pick and choose at run time the platform it prefers to run on. This choice can be dictated by multiple factors including the enterprise policy. This scenario is like your cell phone call being routed through any network available based on existing arrangement and cost to the service provider. As a consumer you don't care how it is routed as long as it is routed and not dropped.
In such a scenario, what choices would the code want to be offered? Certainly not Windows or Solaris or Linux. It is going to be .NET or Java. The code would expect these two frameworks to interpret the high level declarations in the code and compile it into binaries that are appropriate for the underlying platform.
The point is the code couldn't care less if the system has solaris or linus or windows. All the code cares for is it is given a filesystem to store data, a communication system to send/receive messages and a visual system to display its output or take input. It would like to carry out all these transactions in a secure fashion and if not, it would like to be told that.
So why is Java still be released as a SDK? Isn't it time for Java OS? If you look at JDK, it uses the underlying OSes filesystem, communication system, security system and visual system. In an interoperable world, these would become run-time options for the code.
What has changed is the "S" in the OS. It used to be one system now it is a datacenter system.
In such a scenario, what choices would the code want to be offered? Certainly not Windows or Solaris or Linux. It is going to be .NET or Java. The code would expect these two frameworks to interpret the high level declarations in the code and compile it into binaries that are appropriate for the underlying platform.
The point is the code couldn't care less if the system has solaris or linus or windows. All the code cares for is it is given a filesystem to store data, a communication system to send/receive messages and a visual system to display its output or take input. It would like to carry out all these transactions in a secure fashion and if not, it would like to be told that.
So why is Java still be released as a SDK? Isn't it time for Java OS? If you look at JDK, it uses the underlying OSes filesystem, communication system, security system and visual system. In an interoperable world, these would become run-time options for the code.
What has changed is the "S" in the OS. It used to be one system now it is a datacenter system.
Friday, April 16, 2004
Brower based apps and Longhorn
Adam Bosworth writes about browser based apps on his blog. Here is my response.
You caution the world on possbility of Microsoft taking the applications back to the desktop away from the browser. I feel your argument is as valid as some hardware designed skimping of memory because in the old days memory was expensive.
The compelling reason for deploying browser based applications was that such applications are cheaper and easier to maintain thereby saving the enterprise money etc. That was the desktop centric argument. Then came mobile computing and that reasoning was further strengthened because we now have multiplicity of devices.
Those compelling reasons are no longer valid in today's world of falling cost of semi-conductors, software and services i.e. global deflation.
The clients side mobile or desktop is getting richer, cheaper and ubiquitous without sacrificing variety. If the application is not able to exploit this, the application is not worthy of deployment. While you may argue that browser based application lower the cost of deployment and will therefore be deployed not matter what, think again, because the global economics is showing that cost cutting is not the dominant framework but productivity enhance is.
The pendulam had swung too far into the browser based apps domain and I hope Microsoft bring it back to the desktop domain a little for those of us who hate to use browser based applications because of it very unproductive UI.
You caution the world on possbility of Microsoft taking the applications back to the desktop away from the browser. I feel your argument is as valid as some hardware designed skimping of memory because in the old days memory was expensive.
The compelling reason for deploying browser based applications was that such applications are cheaper and easier to maintain thereby saving the enterprise money etc. That was the desktop centric argument. Then came mobile computing and that reasoning was further strengthened because we now have multiplicity of devices.
Those compelling reasons are no longer valid in today's world of falling cost of semi-conductors, software and services i.e. global deflation.
The clients side mobile or desktop is getting richer, cheaper and ubiquitous without sacrificing variety. If the application is not able to exploit this, the application is not worthy of deployment. While you may argue that browser based application lower the cost of deployment and will therefore be deployed not matter what, think again, because the global economics is showing that cost cutting is not the dominant framework but productivity enhance is.
The pendulam had swung too far into the browser based apps domain and I hope Microsoft bring it back to the desktop domain a little for those of us who hate to use browser based applications because of it very unproductive UI.
Thursday, April 15, 2004
Jini and Jxta and Grid Services
So I keep getting asked why not use Jini for grid discovery and Jxta for network independence in grids. Most of the folks who asks actually are not able to tell me what is the distinction between Jini and Jxta. Anybody have a real simple way of explaining? I will give it a try below
Jini is a technology for communication in a distributed computing environment. At the time it was formulated, platform independence was all the craze and thus Jini was born to essentially make RPC platform dependent. But like Java platform it is dependent on the Java language. Like RPC, I believe Jini's communication model is synchronous. The new JavaSpaces builds on top to give a shared memory asynchronous model for communication.
Jxta is a technology for extending distributed computing across a WAN which by definition is heterogeneous. Therefore Jxta involves network protocol routing and is based on asynchronous communication. The problem I see is that it does not use existing IP infrastructure for addressing and therefore not very scalable.
If doing a global grid, I would just move to globus. It solves most of these issues and has a wider following.
Jini is a technology for communication in a distributed computing environment. At the time it was formulated, platform independence was all the craze and thus Jini was born to essentially make RPC platform dependent. But like Java platform it is dependent on the Java language. Like RPC, I believe Jini's communication model is synchronous. The new JavaSpaces builds on top to give a shared memory asynchronous model for communication.
Jxta is a technology for extending distributed computing across a WAN which by definition is heterogeneous. Therefore Jxta involves network protocol routing and is based on asynchronous communication. The problem I see is that it does not use existing IP infrastructure for addressing and therefore not very scalable.
If doing a global grid, I would just move to globus. It solves most of these issues and has a wider following.
Subscribe to:
Comments (Atom)