Maintaining the Core – Service Repository - Applied SOA Patterns on the Oracle Platform - page 303

ReceiverEndpointUserName=""
ReceiverEndpointPrivateKey=""
SenderEndpoint="/Box/System/Out/" MsgId="83"
MsgFileName="PurchaseOrder" MsgFileExt="xml"
MsgLogLevel="3" MsgDescription="PurchaseOrder"
MsgConsolidatedFlag="N" MsgGroup="Order"
MsgCode=""
MsgHeaderVersion="" SchemaFilename=""
StylesheetLocation=""
FieldSeparator="" ElementSeparator=""
TermSeparator=""
MsgHeader="" MsgFooter=""/>
<TPProcessTask TaskId="2"
ProcessTaskDescription="Translate"
…
</TPProcessDescription>
</TPProcess>
Horrible, isn't it? However, we will not discuss the pros and cons of putting task paramet-
ers into the XMLNode attributes or present them as elements to parse/traverse simplicity.
Also, incompliance with the XML elements' naming standard is not a huge crime, al-
though it should be avoided. What you clearly see from this example is that the attempt to
devise an all-occasion task with all the possible parameters leads to a mess. We got
everything here: a path to transformation XSLTs (transformation task), delimiters and ter-
minators for the EDI file translation (translation task), service engine descriptors for non-
WS tasks, a process-logging level flag, a task-logging level flag, and so on. Truly, when
you start expanding the parameter list, it's really hard to stop.
We need some guidance here to find a way to classify our major SOA artifacts and service
particulars and rationalize their storage and extraction. Designing it as vendor-independ-
ent will eventually show us how this can be deployed on Oracle tools: Repository and Re-
gistry. Therefore, let's prepare the playground by installing Repository first. The tax-
onomy provided by Registry is UDDI based, so we will return to it a bit later in this
chapter.