DDevelopment & Design

Apache HISE. Nowy element otwartego stosu aplikacji SOA.

Apache HISE (Human Interactions Service Engine) to projekt, którego celem jest implementacja specyfikacji WS-HumanTask (Web Services Human Task). Specyfikacja ta opisuje zadania wykonywane przez ludzi jako usługi podlegające mechanizmom orkiestracji. HISE znajduje się obecnie w inkubatorze Apache. Obsługa procesów biznesowych jest zwykle realizowana za pomocą orkiestracji usług sieciowych. Mechanizmem tym steruje język BPEL (Business Process Execution Language). BPEL pozwala na definiowanie procesów w usługach sieciowych oraz koordynację wywoływania zewnętrznych usług. Język BPEL pozwala wyrazić konstrukcje zgodne z paradygmatem programowania strukturalnego, a jednocześnie umożliwia tworzenie równoległych ścieżek wykonania. Human Task w SOA BPEL jest dojrzałym produktem. Nie daje jednak możliwości opisu procesów wymagających zaangażowania ludzi. Tymczasem interakcje z ludźmi są istotnym elementem każdego, nawet najbardziej zautomatyzowanego, procesu biznesowego. Potrzeba znalezienia w SOA odpowiedniego miejsca dla usług realizowanych przez osobę ujawnia się zawsze podczas prac nad integracją usług w przedsiębiorstwach. Odpowiedzią na tę potrzebę jest wydana w 2007 roku, po kilku latach gromadzenia doświadczeń w dziedzinie integracji, specyfikacja Web Services Human Task. Implementacja WS-HumanTask stwarza możliwość szerszej adaptacji technologii BPEL. Celem specyfikacji WS-HumanTask jest umożliwienie włączenia zadań realizowanych przez ludzi do istniejących już mechanizmów orkiestracji. Aby było to możliwe, zadania te muszę być traktowane przez system jak zewnętrzne usługi. Dlatego zadania WS-HumanTask składają się z jednej strony z interfejsu wyrażonego przy pomocy WSDL i opisującego usługę, z drugiej – z zestawu funkcji pozwalających na zarządzanie zadaniami. W tej sytuacji fakt realizacji usługi przez osobę, a nie przez komponent systemu informatycznego, nie ma znaczenia. Specyfikacja WS-HumanTask opisuje sposób definiowania usług i cykl życia zadań w powiązaniu z rolami osób je obsługujących. Komponent implementujący specyfikację wczytuje definicje zadań (human task definition) zawierające: specyfikację WSDL usług realizowanej przez zadania, użytkowników mogących realizować zadania bądź nimi zarządzać, sposoby eskalacji i informacje o oczekiwanych czasach wykonania, informacje o sposobie prezentacji na liście zadań i sposobach realizacji w różnych środowiskach klienckich. HISE w opensourceowym stosie SOA Znajdujący się obecnie w inkubatorze projekt Apache HISE będzie w pełni implementował specyfikację WS-HumanTask. Rozwiązanie będzie dystrybuowane w postaci modułów pozwalających na uruchomienie w różnych środowiskach. W tej chwili utworzone dystrybucje pozwalają na uruchomienie aplikacji w kontenerze serwletów lub jako komponentu OSGi w ServiceMix4.

— Previous article

Zwinne szacowanie na AgileWarsaw

Next article —

SpringWeb + Hibernate + Database encoding problems - solved!

You May Also Like
DDevelopment & Design

Journal.IO 1.3 released

AboutJust a moment ago (in February 17th) Journal.IO 1.3 has been released. Journal.IO (https://github.com/sbtourist/Journal.IO) is a lightweight, zero-dependency journal storage implementation written in Java. We use it in our project for storing appl...AboutJust a moment ago (in February 17th) Journal.IO 1.3 has been released. Journal.IO (https://github.com/sbtourist/Journal.IO) is a lightweight, zero-dependency journal storage implementation written in Java. We use it in our project for storing appl...
DDevelopment & Design

Grails render as JSON catch

One of a reasons your controller doesn't render a proper response in JSON format might be wrong package name that you use. It is easy to overlook. Import are on top of a file, you look at your code and everything seems to be fine. Except response is still not in JSON format.

Consider this simple controller:

class RestJsonCatchController {
def grailsJson() {
render([first: 'foo', second: 5] as grails.converters.JSON)
    }

def netSfJson() {
render([first: 'foo', second: 5] as net.sf.json.JSON)
    }
}

And now, with finger crossed... We have a winner!

$ curl localhost:8080/example/restJsonCatch/grailsJson
{"first":"foo","second":5}
$ curl localhost:8080/example/restJsonCatch/netSfJson
{first=foo, second=5}

As you can see only grails.converters.JSON converts your response to JSON format. There is no such converter for net.sf.json.JSON, so Grails has no converter to apply and it renders Map normally.

Conclusion: always carefully look at your imports if you're working with JSON in Grails!

Edit: Burt suggested that this is a bug. I've submitted JIRA issue here: GRAILS-9622 render as class that is not a codec should throw exception