Discussions

News: Enterprise J2ME: Managed Smart Clients

  1. Enterprise J2ME: Managed Smart Clients (7 messages)

    This chapter, excerpted from Enterprise J2ME, by Michael Juntao Yuan, discusses the benefits and architecture of managed smart clients and introduces the OSGi (Open Services Gateway initiative) specification. Through a simple echo example, it demonstrates how to build 'bundles', implement required life-cycle methods, expose and consume bundle services, add UIs to a bundle app, and more.

    Read Managed Smart Clients

    Threaded Messages (7)

  2. OSGi seems an excellent service architecture. If Jini is so good at device federation, why did IBM overlook Jini?
  3. OSGi: Academic Exercise[ Go to top ]

    4 years later nobody knows what to do with this (or if you do, please let me know).

    OSGi doesn't standardize enough to be useful. It doesn't standardize the protocol between the management server and the client device, nor the dependency model between services, so different implementations aren't compatible.

    The user interface is based on servlets. If I wanted a boring old HTML interface to my app, why wouldn't I just move it server side? Anything interesting requires connectivity or horsepower anyway. Take their pizza example; who will fulfill that pizza order? This is a serious question that can't be answered in the OSGi world. For most client-side apps, I want the flexibility of a UI library, not just HTML/HTTP. Compare to the J2EE world, where the "client container" knows how to connect to the server, and offers Swing UIs.

    If I have a headless device, e.g. a router, HTML/HTTP might be a good option for the UI. But I fail to see how downloading bundles onto this is going to help much; it's a fixed-function appliance that doesn't have the oomph to crack every packet in Java, let alone apply much brains to provide some service.

    When Comcast upgraded my existing cable box to offer true video on demand, complete with ordering, without me touching it, that was COOL! Java was not involved. OSGi is a WOBMAT, we need to get our act together if we want Java to compete at this level.

    Perhaps I am being unduly harsh. IBM does in fact have a "product", or "component", which, in conjunction with many hours of consulting time can be used to solve the problems of your particular enterprise. But the fact that a small piece of it is covered by the OSGi spec is of little use.
  4. OSGi: Real World Usage[ Go to top ]

    4 years later nobody knows what to do with this (or if you do, please let me know)
    Our accounting and order management application runs on top of the Eclipse framework and we are looking forward to making great use of the OSGi layer.
    Our goal is to be able to deploy new services to the client on the fly. A typical scenario would be something like this...the customer orders our data backup service from our web site. So, we deploy the backup service into thier local 'gateway'. The backup service discovers the 'local' services that require backup and hooks up with them. The customer's data starts getting backed up without any intervention required on their part. Not even a visit from some consultant :-).
    This is not some future pie-in-the-sky thing, you can do this kinda thing right now.
    OSGi doesn't standardize enough to be useful. It doesn't standardize the protocol between the management server and the client device, nor the dependency model between services, so different implementations aren't compatible.
    You lost me on the part about different service implementations not being compatible. OSGi services are just interfaces, and the semantics of the standard services seems fairly well defined to me. What's the problem?
    The user interface is based on servlets.
    OSGi doesn't define a UI, that's part of the SMF. See the Eclipse RCP (Rich Client Platform) for an example of an OSGi-based GUI framework that is not HTML based.
    When Comcast upgraded my existing cable box to offer true video on demand, complete with ordering, without me touching it, that was COOL! Java was not involved.
    Just out of curiousity - how do you know that Java was not involved? The fact that Comcast might be using Java and OSGi would be transparent to you.

    ted stockwell
    rpcsoftware.com
  5. Solution looking for problem...[ Go to top ]

    Our accounting and order management application runs on top of the Eclipse framework and we are looking forward to making great use of the OSGi layer.
    Looking forward to using is not using. And I think we can safely leave Eclipse out of the discussion. It's just a development tool. Which has a plugin for testing out OSGi bundles with the IBM SMF. Not a "layer".
    Our goal is to be able to deploy new services to the client on the fly. A typical scenario would be something like this...the customer orders our data backup service from our web site. So, we deploy the backup service into thier local 'gateway'. The backup service discovers the 'local' services that require backup and hooks up with them. The customer's data starts getting backed up without any intervention required on their part. Not even a visit from some consultant :-).
    Your example, to me, poses a lot more questions than it answers.
    1. Who defines the standard "backup" interface to services to be backed up?
    2. Let's imagine SMB/CIFS is one of the services to be backed up. Who gives the gateway the users/passwords for the file shares? And who sets up the file shares anyway?
    3. Alternately, lets imagine there's a local agent on the PC. How'd that get there? And still, who gives it the list of things to back up?
    4. What is this gateway? Is it on the PC, or is it a separate box in the network? Who "owns" it? Who defines the wire protocol between it and its owner's management server?
    You lost me on the part about different service implementations not being compatible. OSGi services are just interfaces, and the semantics of the standard services seems fairly well defined to me. What's the problem?
    1. The standard service interfaces don't do much except keep settings and log stuff (and who knows where the log comes out?) Anything truly interesting, like backup, is up to your imagination, and everyone else's.
    2. As a bundle developer, I can't express dependencies on other services, like any GUI other than servlet, which is required by the spec. At least not in a way that is portable across containers.
    3. The client/server protocol isn't standard. I can't use IBM SMF to manage a client using a non-IBM OSGi container.
    OSGi doesn't define a UI, that's part of the SMF. See the Eclipse RCP (Rich Client Platform) for an example of an OSGi-based GUI framework that is not HTML based.
    OSGi does so define servlet as a standard. Though you could add your own non-standard ones, your bundle wouldn't be portable to clients that didn't support whatever you were using. Claiming that RCP is part of OSGi is pretty mixed up. There is no OSGi service interface that is standardized to make use of it.
    Just out of curiousity - how do you know that Java was not involved? The fact that Comcast might be using Java and OSGi would be transparent to you.
    That was a case of insider information - I work in the cable industry. Which brings up an interesting point: many of the other client platform specs, e.g. MHP/DASE/OCAP, have their own service distribution models that compete with, and IMHO address the details better than, OSGI. Not that I'm an MHP fan either, but their Pizza orderer is in use in the field somewhere in Europe.
  6. Solution looking for problem...[ Go to top ]

    Our accounting and order management application runs on top of the Eclipse framework and we are looking forward to making great use of the OSGi layer.
    Looking forward to using is not using.
    I've been using OSGi for 'business' application development for years, starting with writing my own OSGi engine several years ago; http://servicetango.sf.net. The company I work for has developed a large set of it's own bundles (and Eclipse plugins, which are also bundles). The backup scenario I gave you is something that already exists. I meant I'm looking forward to when my company can make money from it.
    And I think we can safely leave Eclipse out of the discussion. It's just a development tool. Which has a plugin for testing out OSGi bundles with the IBM SMF. Not a "layer".
    The 3.0 version of the Eclipse IDE actually runs on top of an OSGi LAYER, http://www.eclipse.org/equinox/. The IDE itself is actually a bunch of OSGi bundles.
    Our product adds our db, accounting, order management, reporting, & backup bundles to thier GUI, Update service, help system, & HTTP Service (Tomcat) bundles.
    Our goal is to be able to deploy new services to the client on the fly. A typical scenario would be something like this...the customer orders our data backup service from our web site. So, we deploy the backup service into thier local 'gateway'. The backup service discovers the 'local' services that require backup and hooks up with them. The customer's data starts getting backed up without any intervention required on their part. Not even a visit from some consultant :-).
    Your example, to me, poses a lot more questions than it answers.1. Who defines the standard "backup" interface to services to be backed up?2. Let's imagine SMB/CIFS is one of the services to be backed up. Who gives the gateway the users/passwords for the file shares? And who sets up the file shares anyway?3. Alternately, lets imagine there's a local agent on the PC. How'd that get there? And still, who gives it the list of things to back up?4. What is this gateway? Is it on the PC, or is it a separate box in the network? Who "owns" it? Who defines the wire protocol between it and its owner's management server?
    You're missing the point. The customer is not paying to backup any and all bundles in thier gateway. Heck, the customer doesn't even know they have a gateway. They're paying to have thier accounting and customer data backed up. The backup service is designed to work only with our bundles.
    OSGi doesn't define a UI, that's part of the SMF. See the Eclipse RCP (Rich Client Platform) for an example of an OSGi-based GUI framework that is not HTML based.
    OSGi does so define servlet as a standard. Though you could add your own non-standard ones, your bundle wouldn't be portable to clients that didn't support whatever you were using.
    You're interested in developing applications that will work across a wide range of gateways, whereas I'm only interested in developing for the one and only gateway that we will use to deploy our application. We are only interested in OSGi as a development platform. Our application need not stick to only using OSGi standards (but that still doesn't make the Servlet API a GUI API :-)).
    Claiming that RCP is part of OSGi is pretty mixed up.
    I didn't claim that RCP is part of OSGi, I said that the RCP is OSGi-based, meaning that it runs on top of an OSGi layer. It's like if I said that my application is Java-based. It doesn't mean that my application is a Java standard, it means that my application runs on top of a Java JVM.
  7. Solution looking for problem...[ Go to top ]

    You're interested in developing applications that will work across a wide range of gateways, whereas I'm only interested in developing for the one and only gateway that we will use to deploy our application. We are only interested in OSGi as a development platform. Our application need not stick to only using OSGi standards
    Now we get to the truth of the matter. You're using libraries in your application, and that makes your life easier. Some provide UI, and some provide component distribution. The fact that it has some "OSGi" label on it means nothing to you (except maybe PR). That this is some kind of "standard" has only academic value. I'm not knocking good middleware, good libraries, or good IDEs with plugin support. I'm only questioning that this particular spec actually adds value to the middleware and libraries out there. It really doesn't live up to the "open services gateway initiative" moniker if it's just some closed system you've developed. Which isn't a slight to your system either, if it provides value to customers. Standards promote openness, but I haven't seen OSGi used to that effect.
  8. OSGi is in real world :)[ Go to top ]

    Hmm, OSGi was not highly visible in the past because of its embedded nature. Do you care what runs in your car or in your TV-set top boxes? OSGi has made a lot of in-roads in the automobile and home automation industries in the past without much fanfare. Right now, it is being adopted by the mobile phone industry. Check out JSR 232.

    For developers, OSGi is just another microkernel -- not much different from JBoss (BTW, JBoss is making in-roads in the embedded manufacturing sectors as well) and other AOP/IoC "frameworks". So, the HTML UI example given in the chapter is just an illustration. You are free to develop rich UI (like IBM SWT) applications on top of OSGi. In fact, this is exactly what the new Eclipse Rich UI platform does.

    Having said that, the HTML pizza example does have values: you can now queue your orders in the local device when the network is not available (a common problem with wireless devices). Purely server driven applications simply do not work on wireless devices (remember WAP browsers? They are painful to use).

    cheers
    Michael (the author)