O núcleo fornece interfaces adequadas para a manipulação de uma Rede de Petri. Entretanto, uma Rede de Petri não é suficiente para descrever um WF. Um WF é composto por WorkItens, e estes, por sua vez, estão associados a telas, campos, botões, agentes e ações. O problema de relacionar esses elementos de maneira consistente e eficiente é um pouco mais complicado do que parece, pois existem as chamadas instâncias de um WF.
As instâncias de um WF são, abstratamente, clones de um WF. Cada instância está associada a um único WF, além de possuir seu próprio estado e ser independente de outras instâncias. De uma certa maneira, uma instância possui um tipo, ou seja, ao olharmos para uma instância podemos dizer a qual WF ela está associada. O único elo de ligação entre duas instâncias de um mesmo ``tipo'' é o WF do qual foram clonados.
Para entrarmos num campo mais familiar, podemos fazer a associação de instâncias de um WF com as instâncias de classes presentes no paradigma de Programação Orientada a Objetos (POO), onde as classes poderiam ser interpretadas como sendo os WF's. Do mesmo jeito que no paradigma POO, onde um objeto (instância de uma classe) possui estados, membros e métodos para a manipulação de seus membros, uma instância de um WF também possui estados (os estados descrevem em que fase do processo um WF se encontra - é basicamente para esse controle de estados que o núcleo foi desenvolvido), membros (campos, botões, telas e agentes associados) e métodos que são nada mais do que interfaces flexíveis para a manipulação de seus membros.
Para a representação desses elementos na modelagem do sistema, fez-se uso de metaclasses. A idéia de metaclasses está relacionada à possibilidade de criar classes em tempo de execução, ou seja, criar novos tipos (WF's) sem alterar o código do sistema. Optou-se por essa idéia pelo fato de metaclasses serem flexíveis, configuráveis e facilmente adaptáveis. Tanto o núcleo como as extensões utilizaram essa idéia através da aplicação do padrão TypeSquare (ver [5]) o qual permitiu descrever e relacionar tipos de dados e instâncias desses tipos de maneira eficiente e consistente.
Além disso, foi utilizado o padrão Fachada para evitar que camadas superiores tenham acesso direto aos mecanismos de persistência de dados, ou seja, a única maneira de realizar persistência de dados é através das interfaces fornecidas pelos chamados Beans de Fachada. Os Beans de Fechada são classes que seguem um padrão estabelecido pela arquitetura J2EE e são utilizados pelo contêiner J2EE para prover facilidades quanto à segurança e chamada de métodos remotos. A chamada a esses métodos pode ser feita por qualquer camada acima da camada de negócios.
Como dito, camadas superiores não têm acesso direto aos mecanismos de persistência de dados, entretanto, como em muitos sistemas, determinados dados precisam ser persistidos. No caso, a camada de apresentação provê interfaces para entrada de dados ao usuário que precisam ser persistidos. Para repassar esse dados à camada de negócios, para que ela realize a persistência deles, foi utilizado o padrão Data Transfer Object (``Objeto de Transferência de Dados''), também conhecido como DTO. O padrão DTO encapsula os dados num único objeto. O benefício desse padrão é evidente, pois ao invés da camada de apresentação realizar diversas chamadas remotas à camada de negócios para a persistência de cada dado, faz-se uma única chamada remota, passando o DTO, com todos os dados encapsulados, como parâmetro.