Folks,
In terms of implementation, we have discussed several aspects:
1) There are several potential ways in which MDP messaging can be implemented.
2) The Jt Design Pattern framework is a reference implementation of MDP. It is
also a good source for implementation information, documentation, examples,
applications, etc.
The following section deals with some implementation related questions. In
particular, it deals with type safety and detection of errors during
compilation. Feel free to let me know if you have any additional
questions/comments on this topic.
On terms of the example contained in the paper, processMessage/sendMessage are
used for communication (messaging) only. You will need other primitives for
component lookup, creation, read, update and deletion. In Java for instance,
you will usually have getters and setters to set and retrieve the value of
component attributes. Other technologies/languages provide similar facilities
to access/update components. These additional primitives do not impact
coupling(communication between independent/decoupled components is performed
via messaging). I hope this clarifies some of the questions related to the
example contained in the paper. In summary, getters and setters are OK. They
are used to initialize the components before the message is transferred to the
remote component/service. On the other hand, local component, remote component
and messaging mechanism are independent entities, fully decoupled via
MDP.Conceptually you are sending a message to a remote
component/service via its proxy:
sendMessage (proxy, message);
The MDP framework is responsible for delivering the message.
Best Regards,
Al
MDP Implementation
Similar to the software model, the MDP implementation should also mimic the
reality being modeled. There will probably be some implementation differences
depending on the specific application. There are many factors to consider based
on the type of messaging being implemented and the technology/language in use:
messaging delivery characteristics, streaming, messaging reliability,
asynchronous messaging, security, etc.
The MDP interface (JtInterface) is mainly a reference implementation and there
are other potential implementations of the messaging abstraction:
public interface JtInterface { Object processMessage (Object message); }
The generic type object is used. This is similar to the implementation of other
design patterns (Iterator, for instance). In reality, the component may only be
able to process and return specific types of message. In that case, appropriate
types may be specified. For instance:
public interface MyMessagingInterface {
MyOutputType processMessage (MyInputType message); }
This is also a valid implementation of messaging. Advanced object oriented
technologies provide features like Java generics which allow the types to be
parameterized:
public interface MDPInterface<Type, Type1> { Type1 processMessage (Type
msg); }
Notice that any computer language or technology can be used to implement MDP
messaging including plain old java objects (POJOs):
public Object processMessage (Object message)
Depending on the application, a second messaging primitive may be needed:
public Object sendMessage (Object component, Object message);
This primitive sends a message to a local or remote component. Although MDP
messaging features a simple implementation, based on basic primitives, it is
able to transparently handle complex real-world scenarios: remote components,
synchronous/asynchronous/two-way communication, component interoperability,
multithreading, streaming, authentication, encryption, exception handling,
reliable messaging, etc. As mentioned earlier, the concept, messaging is
simple, versatile, robust, etc. Messaging can also be made reliable, secure,
redundant and fault-tolerant. By including messaging, the model and the
implementation absorb its inherent qualities.
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
