Discussions

News: Crispy releases first stable version 1.0

  1. Crispy releases first stable version 1.0 (12 messages)

    The first stable version 1.0 of Crispy, a lightweight API, has been released. Crispy invokes remote services with a single point of entry for different kinds of transport providers (RMI, CORBA, JAX-RPC, XML-RPC, EJB, Hessian, Burlap, REST and others). It works by using properties to configure a service manager, which is then used to invoke the remote API. Crispy provides a layer of abstraction to decouple client code from access to a service, as well as its location and underlying implementation. Features include: - Transport providers that are easy to change with new configuration - Remote invocations that are transparent - Supported synchronous and asynchronous execution - Supported interceptor - Modified or extended method parameter and result Crispy can be combined with other frameworks, such as Spring, HiveMind, PicoContainer, OSGi and AspectJ. What do you think of Crispy?

    Threaded Messages (12)

  2. What about jini?[ Go to top ]

    A Jini service can register on a LUS with a proxy. Which means that a client that connects a jini service dynamically loads a proxy. Then the client connects the service using this proxy and not directly. Guy
  3. Re: What about jini?[ Go to top ]

    It is possible to integrate Jini in Crispy. If you implement a StaticJiniProxy and send me the implementation (with a description and tests), I want to to publish it (read the developer guide).
  4. What's the point?[ Go to top ]

    Really how often do you ever want to swap out these layers? Is there any business reason to do so? The transport layer in question here is usually the foundation for a solid n-tier architecture. Why would you swap them out? Oh, and I just created a new framework called Soggy that wraps the Crispy framework. So in case anyone wants to swap out Crispy someday with another abstraction layer they can do so.
  5. The Point is...[ Go to top ]

    ...some people aren't convinced that basing client code on J2EE is a good idea - usually CORBA people who are sour and hope one day we'll all relize how much better CORBA services are than J2EE. They're protecting us from our own short-sitedness ;-) But, there surely are cases where a client should use a business delegate with multiple, swappable implementations -unit tests come to mind. What I prefer to do is use the existing, rock-solid Context/Home/Remote paradigm by loading up the mock implementations in a home-brew InitialContext. No need to reinvent the wheel.
  6. Re: What's the point?[ Go to top ]

    The idea from Crispy is the separation of the remote technique from the business logic. Define a service interface for the business logic and define (configure) on the other place the remote technology. The business logic must be a long living component (in contrast to the short living technology). Every body can programming with a interface, but not every know how make a XML-RPC or RMI call. The second point is, with Crispy can you easy switch from one to another remote technique (e.g. by performance problems). A other important property is the interceptor concept. Before or after method calls (or on error) can separate the different aspects, how logging, time stopping, security, monitoring or other. And so on ... Is this plausible?
  7. Re: What's the point?[ Go to top ]

    I really like the concept behind Crispy, and your API is light and to the point. It happens WAY too often in large enterprise SOA distributions that you find different technologies on the server side but need to communicate through a single client. I don't see the purpose of juggling all those API's when one will suffice. With that said, I can only wonder: when will we get a server like implementation of Crispy? Sure, Axis and XFire support a bunch of different transfer protocols but I would really like to see your approach on this.
  8. Re: What's the point?[ Go to top ]

    Crispy means “Client for Remote Invocation for different kinds of Services via ProxYs”. This was the first idea. Today is this idea no more correct. Client without a Server is not really a good think, You have right. In the next releases is the server side a important topic for Crispy.
  9. Re: What's the point?[ Go to top ]

    The asynchronous communication is a simple implementation. The execution is in a separated Thread. So can after the invocation directly begin the next task, without waiting of the result from the first call. That is all.
    This strategy might not be suitable for long running operations as its susceptible to network timeout issues. It also leaves the socket open until the the remote call returns. Lingo uses JMS for asynchronous messaging and hence doesn't suffer from these drawbacks since the caller returns on the same thread after the method is called (i.e. the message is published) and the return value is received by the listener on another thread. Sanjiv
  10. Re: What's the point?[ Go to top ]

    Oh, and I just created a new framework called Soggy that wraps the Crispy framework. So in case anyone wants to swap out Crispy someday with another abstraction layer they can do so.
    I might be interested in a pre-alpha release of Soggy, but only if you promise to loose interest in it within 3 weeks and move on to designing your own logging meta-framework and O/R mapping layer!
  11. Hi Mario,
    Crispy can be combined with other frameworks, such as Spring, HiveMind, PicoContainer, OSGi and AspectJ.

    What do you think of Crispy?
    Since you mention Spring, with regards to syncronous remoting however, this seems to have an incredible amount of overlap with Spring Framework's remoting. I can't see much of a reason why you'd want to use this instead of Spring's own remoting in a Spring environment. Actually, given that Spring remoting can be used completely like a utility library (people often create stubs and exporters in a declarative fashion in the Spring IoC container, but in act the remoting functionality is usable programatically), I'm not sure why anybody would prefer the Crispy functionality instead of just using the more mature and well tested Spring Remoting. (Also, although I have not played around much with it, JBoss have also introduced a similar library). Can you give a reason (choice aside, and we do know choice is good :-) ), why this would be a better choice than Spring remoting? Spring Remoting support a number of protocols, with both dynamic stub generators on the client side, and transparent service exporters on the server side: Hessian: client side and server side Burlap: client side and server side HttpInvoker (Java Serialization over HTTP): client side and server side JaxRPC: client side RMI: client side and server side RMI over Corba IIOP: client side and server side Corba IIOP: client side WebLogic T3: client side and server side (shipped by BEA) EBJ (local & remote): client side The list of Crispy protocols is visible on this page here: http://crispy.sourceforge.net/guide_user.html Btw, is the Crispy "Http call with Java Serializer" protocol compatible with the Spring remoting HttpInvoker protocol? It looks very similar. The mention of async operations looks sort of interesting. Can you flesh that out a bit more, in terms of what it does? There is actually a library at CodeHaus called Lingo which is based on Spring Remoting, but adds async functionality. How does Crispy compare to that? http://lingo.codehaus.org/ http://www.springframework.org/node/276 http://www.springframework.org/node/275 Regards, Colin
  12. Hi Colin, The main motivation for Crispy is a easy configuration (with Properties). Every projects have your own XML syntax and the developer must by every Framework learn this new syntax. It is not a valuation, this was my start point. The properties are not so powerful how XML, but easy to use (key and value, not more). Spring is a very interesting and powerful Framework. I use Spring in different projects. This is no reason for me, don’t develop the Crispy Framework (how O/R mapper: Hibernate, TopLink, Apache OJB, iBatis, Cayenne and more other). Everybody can choice the best for your requirement. Best regards, Mario. The combination with Spring was a experiment. It show, that Crispy is easy to integrate and can play with other Frameworks. One technology is from Spring not supported: XML-RPC ;-) . It is a transport provider with good performance and supported from different programming language. The asynchronous communication is a simple implementation. The execution is in a separated Thread. So can after the invocation directly begin the next task, without waiting of the result from the first call. That is all. I haven’t tested the compatibility from “Http call with Java Serializer“. It is a interesting question.
  13. for as long as remoting APIs have existed they have promised to allow us to "concentrate on the business logic" while in reality forcing us to write infrastructure-centric code like RemoteException or PortableRemoteObject.narrow() or @WebServiceRef. so there is a point in hiding the differences in transport layers and remoting APIs. however, to be honest, i think the abstraction that Spring has been providing for a couple of years works perfectly well: client code is written against a remoting-agnostic Java interface specification of the (remote) service, and the IoC container injects an object/client stub/proxy implementing that interface. all configuration required to look up and invoke the remote service is just that: configuration (of/for Spring). i do not see the need for an actual unifying *API* in this scenario... cheers, gerald http://www.gerald-loeffler.net