The work I did in Preferred class loading was all about not downloading when not necessary. It let the client declare the platform. This can be done in a couple of different ways now, but that's something to consider when reducing the complexity of a deployment environment.
Gregg Sent from my iPhone On Jan 29, 2012, at 4:37 AM, Peter Firmstone <[email protected]> wrote: > So for business, you could set up request for tender systems, contracting > companies would need to apply to be added to a tender approval list. > > Then from the early beginnings, a project could be estimated, quoted, > prepared, executed and completed using separate company systems that > interacted with each other using standard service interfaces, to share > information combined together to produce dynamic complex systems, that can be > used to track and link all relevant information. > > But that could be a pipe dream, other applications might be distributed > social networks, complete with graphics and video, textual chat and other > interfaces. This sort of software could be developed and advanced rapidly, > no reliance on prior protocol deployment or different protocol versions or > upgrades. Java platform deployments are relatively long lived. The trick > will be to make UI's simple and intuitive. Service UI's don't have to be > dynamically downloaded for every service, and they don't need to originate > from the underlying service, a service UI could be common to many global > distributed services with an identical Service API. An app service might > simply provide downloads of Service UI (with signed jars) for other popular > services, the service UI actually appears as the application to the user, it > might consume a number of services, which could be dynamically discovered. > > Just some thoughts, I think the possibilities are only limited by > imagination, time, ability and a few java platform limitations. > > Cheers, > > Peter. > > Peter Firmstone wrote: >> Well, I think it's possible to do most things with web based services, using >> style sheets html and javascript on the client and java or modperl on the >> server, usually with an SQL database behind that. What happens though is as >> you develop this, it becomes unmaintainable the java or perl code get's tied >> to the database structure, the javascript might do some local client >> processing before submitting forms etc, then you start looking for something >> to abstract the database, but everything becomes very difficult to manage >> and support over different browsers due to fragmentation, so you try and >> standardise your IT deployment environment, then this forklift upgrade cycle >> develops, where you have a system upgrade period where nothing works >> properly. But it's the old 3 tier server and client model. This is tied to >> HTML and TCP/IP. >> >> But this is what people know and it's majority rules. >> >> I guess you could sort of argue that Java has become fragmented too, I mean >> if you consider Android a form of Java and you've got Java EE, SE, ME CDC >> and CLDC, blue ray, embedded SE and RTSJ and all the various versions. >> >> But then if you settle for Java SE, JERI CORBA for C+ / C++ back ends and >> use Surrogate for the ME stuff, you're pretty well covered. >> >> But that's not what this is about, by using Interfaces, services can become >> mix-ins, or runtime dependency injected, so it no longer matters to the >> client what the server does, where or how it stores its data, whether it's >> served by a legacy back end system, what communication protocol it's using >> etc. It's not about what they can do and what we can do, if that's what we >> focus on, we've already lost, it's about maintenance cost. >> >> It costs more to maintain business software than it does to write it, now >> most programmers might tell me I'm talking crap, however I'm not a >> professional programmer and have a different perspective, which might be a >> breath of fresh air, or just totally wrong, I'm a Mechanical Project >> Engineer / Project Manager, working with Mega Machinery, eg Big, Bigger, >> Biggest, shows you see on the telly, software must adapt to business and >> business processes, must be made as efficient as possible, with as little >> bureaucracy as possible. But too often in business I see the tail wagging >> the dog, IT, HR, Safety, Legal and Accounting departments are support >> infrastructure, they're supposed to support the departments that produce or >> bring in income, be they manufacturing, maintenance or customer sales or >> service, they are supposed to find ways of making innovation possible, too >> often they unknowingly stand in its way. Too often the power lies with >> those that control infrastructure and everyone else tries to work around >> documented policy and process, simply because infrastructure doesn't fit the >> business. Typically IT software and hardware companies deliberately >> introduce incompatibilities into their systems, differentiating features, >> especially if they've gained a large market share, it becomes part of their >> market strategy, along with patents and copyright laws: intellectual >> property. I once heard someone say: "Ideas are worth nothing, if you don't >> have execution." >> >> Workers used to worry about automation putting them out of work, however >> today, complex government legislation has created more work than automation >> ever replaced, it's how rich countries keep their populations employed. >> Money that changes hands (payroll) is highly taxable, money itself is partly >> an illusion, when lending is high, or there's an international trade >> surplus, increasing the availability of money, we have booms and when >> there's a shortage, bust. Countries trade in treasury certificates, IOU's, >> it's bad (for both countries) when a country can't repay the interest on >> it's IOU's. Money is created in production and destroyed in consumption, >> you'd think that government would legislate the amount of available credit >> based on international trade surplus / deficit and GDP, then tax credit >> creation at a fixed rate (requiring a referendum and vetting by a broad >> knowledge base to alter), abolishing all other taxes, it would stop the >> boom bust cycle and you wouldn't need the complexity of current taxation >> systems, interest rates would be based on competition between lenders, not >> monetary policy. Government would be forced to promote production and >> innovation, to increase their tax base, rather than creating new taxes and >> legislation complexity as they do currently. >> >> But I'm in danger veering off topic into fantasy land and maybe even talking >> crap. >> >> Using services is a way to create systems that plug in and connect data >> silo's together, join the old with the new and adapt. >> >> I see the hidden costs of software systems unable to adapt to business >> changes, it's tough in business, it is dog eat dog, to be successful >> requires good people skills, understanding your market, your customers and >> competitors. You need your support departments fighting for you, not with >> you. >> IT is the support department that supports all other departments and can be >> a big impediment to progress or an enabler. >> >> To answer the question about the internet, everything is connected, as a >> business grows it branches out and opens up in new locations, the internet >> is a communication channel. >> >> If River can't communicate / traverse the internet, it becomes a legacy data >> silo, it can't expand with the business, it can't fully service the >> businesses needs. >> >> River could be the glue that works with everything else, or it can remain in >> a niche and be consigned to history. >> >> River still has some Java platform warts, but they're not as bad as the >> html, sql, javascript worlds warts. Systems need to be efficient and clean, >> even the simplest tasks can become daunting when dealing with some of >> today's web pages. Computers can automate and simplify complex tasks, or >> they can make the simplest task a nightmare, it depends on the implementer. >> >> That's why I contribute development time, to use River in my business, it >> needs to do some basic things it can't do presently. To do things no one >> else can; adapt quickly for a competitive edge. >> >> Cheers, >> >> Peter. >> >> Gregg Wonderly wrote: >>> This is one of those places where Jini's power, using mobile code, creates >>> more "necessary" overhead, than people familiar with other forms of >>> "marshalling" start to wonder "why would you do that then?" I think it's >>> important to look at what "external mechanisms" Jini is using now, and >>> start looking at providing other forms of "marshalling" at the >>> InvocationLayerFactory level. >>> >>> Simple, "document transfer", is what it seems many people feel is "tenable" >>> for them in enterprise level systems. I've long argued, that the Jeri ILF >>> is actually just like a "document transfer", in that the method arguments >>> are sent, in a package, to the server, whose "invoke" action is passed this >>> "document." The remote server then processes the document and returns it, >>> potentially with a "hyper link", in the form of a remote reference or just >>> the resultant "value." The type information available from the result, is >>> the "complete, self documenting" description. It tells you what you have >>> and what you can do with it. >>> >>> It's this simple view of the "Jini transport", that would enable a lot of >>> different possible mechanisms to be used at the ILF layer. Because I've >>> never really had the need for anything else, I don't have anything in >>> production different than the standard Jeri ILF. But, I did, at one point, >>> create an ILF that did do MODBUS-over-TCP as an exploration of what it >>> would mean to move something, which I could do at the "service layer" via a >>> "delegation model", into a lower level interface. >>> >>> What I found, was that there wasn't a "distinct" advantage, so I threw that >>> stuff away and just kept it at the service implementation level. This is >>> one of the things that I found important to understand about Jini. It >>> works well as a layer of communications and unification of interface, that >>> enables features that are not what the "service" is about, but rather what >>> "distributed systems" are about. So, as a tool set, it works well for that >>> specific task. >>> >>> Things like Rio, JavaEE integration, Realtime systems monitoring etc, are >>> the "domain" targeting mechanisms that enable specific types of system >>> "construction" which in turn can enable specific kinds of "features". Rio >>> lets you build lots of "small" or "large" services and get all the dynamic, >>> built-in, life-cycle management features that a large enterprise >>> environment needs. The Harvester and other such systems, provide ways to >>> use Jini features inside of a JavaEE environment to take advantage of >>> "both" tool sets together. The dedicated solutions world, which has >>> plagued the Jini platform with no "demonstrable" users, is what we've >>> always held up and waved around, saying, "people feel it's so valuable to >>> them, that they don't want their competition to "see" or "know" how they >>> are using it. >>> >>> So, there is the whole other side of the internet, on untrusted networks, >>> where people are constantly using the "Web" for their transactional, data >>> transport systems/models. I'm not sure where Jini fits in that world, >>> without some very specific, dedicated systems that do stuff that the web >>> can't do. Looking for some of that "lone" fruit to pick, is what I'm not >>> sure about. >>> >>> What kind of transactional, leased or other data services could you imagine >>> Jini being a key part of on the Internet? >>> >>> Gregg Wonderly >>> >>> On 1/27/2012 7:04 PM, Peter Firmstone wrote: >>>> I've been thinking about the practicalities of a djinn running in >>>> untrusted networks (internet), the first thing that springs to mind is, >>>> security is much simpler if people can get away with only "dumb" or >>>> reflective proxies. >>>> >>>> I'd like to the see the default security setup requiring >>>> DownloadPermission. >>>> >>>> I we sign our download jars (a number of developers could do this, >>>> requiring at least this group of signers), a standard policy file template >>>> could include a certificate grant for DownloadPermission, allowing anyone >>>> to load classes from a standard River download proxy. >>>> >>>> This gets our smart proxy's out of the way. >>>> >>>> Then all developers need to worry about are Principals and >>>> MethodConstraints, allowing people to get started using River with >>>> reflective proxy's over the internet. >>>> >>>> Later if people want to get into smart proxy's that power's still there, >>>> this change prevents unauthorised class loading. >>>> >>>> Cheers, >>>> >>>> Peter. >>>> >>> >>> >> >> >
