Glyph: Annotations and Utilities for Jini

Discussions

News: Glyph: Annotations and Utilities for Jini

  1. Glyph: Annotations and Utilities for Jini (14 messages)

    The Glyph project, which provides annotations and utilities for Jini, has made its first release. Glyph makes the creation of Jini services much easier than the default tools do, by providing a simple @Service annotation that marks an implementation as an exported Jini service. Jini services are different than typical web services in that they can export their interfaces. Services are located via multicast, which means the service' endpoint doesn't necessarily have to be known ahead of time. However, Jini's acceptance in the industry appears to be fairly limited, even though some specific user communities rely on it heavily. Glyph's annotations, by automating some of the grunt-work associated with publishing services, may help change that somewhat. (The Glyph documentation suggests that using Glyph might change a thirty-minute process of converting a standard remote object into a Jini service down to ten seconds, which might be a highlight of what's slowed Jini adoption down.)
  2. (The Glyph documentation suggests that using Glyph might change a thirty-minute process of converting a standard remote object into a Jini service down to ten seconds, which might be a highlight of what's slowed Jini adoption down.)
    As a note of clarification: The 30 mins Vs 10 secs is to do with the building of the extra code and configuration files required to run and deploy a 'well-behaved' jini service, and doesn't include the time needed to create your Remote Interface and implementation. One thought that always seems to strike many people that wish to use Jini is that it's all very nice and all that, but it is a tad unintuitive as to how to get things running quickly and be developing quickly as well. My hope with Glyph is that we can mitigate some of that by helping developers with some of this heavy scaffolding. The initial release is to gain some feedback and get some ideas both from jini users and those that aren't familiar with the technology to incorporate into the project and help it evolve. The todo list has a list of things that the project might want ot look at including, for instance, tagging Swing components with a @ServiceUI attribute to automatically build the ServiceUI Roles and factories and automatically incorporate them into the services configuration files, and potentially looking at how we can cross build to JDK1.4 for 1.4 clients but still use annotations to drive the process. As a comparison, there is an entry on my weblog that shows how Glyph would help with Dan Creswell's tutorial 'How to write a Jini service' Thanks --Calum
  3. Services are located via multicast,
    That's one way services can be located but there are others that are available by default that don't use multicast and are similar to the means by which one might access a JNDI registry for example.
    which means the service' endpoint doesn't necessarily have to be known ahead of time. However, Jini's acceptance in the industry appears to be fairly limited, even though some specific user communities rely on it heavily.
    Working on that - it's actually being used across a broad number of segments now, just need them to open their moouths and say so.
    Glyph's annotations, by automating some of the grunt-work associated with publishing services, may help change that somewhat. (The Glyph documentation suggests that using Glyph might change a thirty-minute process of converting a standard remote object into a Jini service down to ten seconds, which might be a highlight of what's slowed Jini adoption down.)
    I certainly hope it helps but I also believe it's just one small piece of the acceptance puzzle a lot of which is about dealing with mindset, existing beliefs (lore dating back to '99) and practices.
  4. Hi Jini-platform has many interesting components that should IMHO be useful and available for the rest of Java-platform. One of these components, is Configurator which provides more programmatic way to create and deal with configurations. Any idea how Configurator could be used outside Jini for POJOs?
  5. Hi

    Jini-platform has many interesting components that should IMHO be useful and available for the rest of Java-platform. One of these components, is Configurator which provides more programmatic way to create and deal with configurations.

    Any idea how Configurator could be used outside Jini for POJOs?
    Right, so first thing to say is that the Configuration bits are standalone and Apache licensed so you can use them without the other bits of Jini if you wish. In terms of usage, the model doesn't change whether you're using Configuration for Jini Services or standalone POJO's. If you can provide some more detail of the sorts of things you want to use Configuration for in respect of POJO's, I can give you some pointers.
  6. Hi Dan Thanks for the hints you gave both in Oslo and in this forum. Based on your hint, I looked again at the configurator. However, I did not find any standalone library for it? I am considering to use Configurator for large-scale enterprise GUI applications as it is the closest to a type-safe configuration. Having said that, one other option would be to use Java itself for configuration. I mean an api to let an application to work with various configurations that are written in Java. The configuration could be seen in three levels: 1. Simple, using a property file 2. Medium, using an XML file or a database 3. Complex, Jini Configurator or full-featured Java code Number 3. is relevant for a configuration that the developer after all must be involved, e.g. the rules in a rule engine or validation rules.
  7. Hi Dan

    Thanks for the hints you gave both in Oslo and in this forum.
    Ah, cool - I hadn't tagged you as being at the Oslo meeting. Glad it was useful at least in some small way.
    Based on your hint, I looked again at the configurator. However, I did not find any standalone library for it?
    Yeah, so it isn't packaged up in a little .jar of it's own but you can find what you need in jsk-platform.jar. That's all you'd need. If there's going to be interest in using Config standalone, I'd consider splitting it out into a separate .jar once we get the Apache transition done (on which I'll be a committer).
    I am considering to use Configurator for large-scale enterprise GUI applications as it is the closest to a type-safe configuration. Having said that, one other option would be to use Java itself for configuration. I mean an api to let an application to work with various configurations that are written in Java.

    The configuration could be seen in three levels:

    1. Simple, using a property file
    2. Medium, using an XML file or a database
    3. Complex, Jini Configurator or full-featured Java code

    Number 3. is relevant for a configuration that the developer after all must be involved, e.g. the rules in a rule engine or validation rules.
    Okay so for number 3, I wonder about beanshell also? In respect of configuration complexity, well the Jini config API is very simple and just returns objects which can be as simple as Integer. The default configuration provider uses a Java-like syntax but you could have others that for example used an XML type structure. I'm not sure if the computecycles project don't have that option already developed (certainly Van Simmons has talked about this in the past).
  8. In respect of configuration complexity, well the Jini config API is very simple and just returns objects which can be as simple as Integer. The default configuration provider uses a Java-like syntax but you could have others that for example used an XML type structure. I'm not sure if the computecycles project don't have that option already developed (certainly Van Simmons has talked about this in the past).
    Just to let you know, Glyph will be including a Dependency Injection Engine for POJO's for injecting from Jini Configuration files in it's next releasem; this code is being donated from the Neon project Thanks --Calum
  9. Calum, Dan,

    Many thanks for your evangelist effort. You are doing more for Jini adoption than Sun itself. But what I believe is the biggest obstacle for better adoption are some real-business-world use-case examples. When one scans through what is available on the web about Jini, no matter how appealing it is to technical people, for business guys it is still looks hazy.
    Now, in my company we have a need to connect master-data system (hosting info about countries, currencies, exchange rates, management org. structure,...) with various dependent systems (ERPs, HRs,...). My sixth sense tells me that Jini/JavaSpaces combination would be right way to do it. ;-) But, how to convince decision makers?
  10. "My sixth sense tells me that Jini/JavaSpaces combination would be right way to do it. ;-) But, how to convince decision makers? " Hi Vladica, I'd say that your senses are right. : ) Today there are many success stories and production references for Jini related technologies. Your job in convincing others should be much easier. Let me know if you need any assistance in finding some of these. Owen Taylor owen at gigaspaces dot com http://jroller.com/page/owentaylor
  11. Calum, Dan, [..] You are doing more for Jini adoption than Sun itself.
    Agreed. After dealing with Sun's old attitude on JINI, Dan's pragmatic approach has been a breath of fresh air.
    But what I believe is the biggest obstacle for better adoption are some real-business-world use-case examples.
    This is where (IMHO) Paremus is a bit ahead of the crowd. They realized that JINI was a tool that companies could use to build things that _do_ have "real-business-world use-case examples". I still see very few direct applications of JINI to business problems because it is extremely "low level" on the conceptual stack.
    Now, in my company we have a need to connect master-data system (hosting info about countries, currencies, exchange rates, management org. structure,...) with various dependent systems (ERPs, HRs,...). My sixth sense tells me that Jini/JavaSpaces combination would be right way to do it.
    That is a good example of where JINI is not directly appropriate. You shouldn't need a "sixth sense" to find a use for a technology -- rather, the use case should be literally begging for a particular type of solution ;-) We're working with a number of customers on master data and reference data services, and integration turns out to be 90%+ of the task while the "data management" technology turns out to be relatively straight forward. Tell me, does this match your findings so far? Are you going through a prototyping stage first? (Hint: Pick at least a couple of those various "dependent systems" to include the prototype!) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  12. Now, in my company we have a need to connect master-data system (hosting info about countries, currencies, exchange rates, management org. structure,...) with various dependent systems (ERPs, HRs,...). My sixth sense tells me that Jini/JavaSpaces combination would be right way to do it.


    That is a good example of where JINI is not directly appropriate. You shouldn't need a "sixth sense" to find a use for a technology -- rather, the use case should be literally begging for a particular type of solution ;-)
    Actually this is an excellent example of where Jini technology is appropriate, and precisely where the advantages of a JavaSpace comes in. The loosely coupled semantics that a dynamic service oriented architecture based on Jini technology services provides fit the (set of) use-cases very well. Regards Dennis
  13. That is a good example of where JINI is not directly appropriate. You shouldn't need a "sixth sense" to find a use for a technology -- rather, the use case should be literally begging for a particular type of solution ;-)

    We're working with a number of customers on master data and reference data services, and integration turns out to be 90%+ of the task while the "data management" technology turns out to be relatively straight forward. Tell me, does this match your findings so far? Are you going through a prototyping stage first? (Hint: Pick at least a couple of those various "dependent systems" to include the prototype!)

    It match my findings 100%. But how about integrating 400 ERPs (15+ different kinds - from latest SAP installations, to systems for which appropriate specialist could be found only in fossilized form) scattered around 96 countries? Than, there is always issue of corporate politics. Division1 manager1 would say:"We can do this with this vendor1 SOA product1!". Division2 manager2 would reply:"Ha, ha! Dream about it! We will do it with vendor2 SOA product2!". And there you go...
    SOA fever came...
    Then SOA fever went.
    Now, since "integration" failed, next ingenious idea is "consolidation"... Scary...
    Than, there is a fact that both service providing and service consuming systems are not something that is carved in stone. They constantly (and violently) change: technically, logically, organizationally... Remember, playing with org-charts is very easy! ;-)
    Therefore, every potential solution must be kind of "common denominator". Currently, the only common denominator in our IS landscape is Java (but there is a lot of MS stuff, too!). I believe (hope) that Jini/JavaSpaces just might be pushed to the level of common denominator. It is still (media/maketing)unspoiled and I believe technically/architecturally resilient enough. ...only if one could find more stuff for convincing non-tech guys in potential benefits.
    Of course, I am just guessing. My current knowledge of Jini/JavaSpaces is quite limited. But, I am not lazy...

    Cheers,

    Vlada
  14. politics and silos[ Go to top ]

    It match my findings 100%. But how about integrating 400 ERPs (15+ different kinds - from latest SAP installations, to systems for which appropriate specialist could be found only in fossilized form) scattered around 96 countries? Than, there is always issue of corporate politics. Division1 manager1 would say:"We can do this with this vendor1 SOA product1!". Division2 manager2 would reply:"Ha, ha! Dream about it! We will do it with vendor2 SOA product2!". And there you go...
    I would suggest that you definitely pick a couple of those ugly old ERPs (and make sure at least one from each division is _NOT_ Java) so that you can have a successful POC that doesn't take the easy way out. Also, try to pick them _based on_ politics, instead of avoiding the politics. Basically, you are looking for an ERP system in each division that wants to take advantage of data that has been traditionally inaccessible to them (because it was owned by another division). What master data management does is open up those data conduits so that you can't silo data unless you have very good business reasons for doing so. What are some of the tools that you have been looking at? From the sound of it, you've probably been pitched on various "SOA web services" thingies. They are not all bad though. Have you seen anything that seems workable? Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  15. But what I believe is the biggest obstacle for better adoption are some real-business-world use-case examples.
    +1