Product	Description	Documentation	Download
HttpPostServer	Save hundreds of hours of coding and testing. Accepts uploads and neatly organizes files. Accepts automated (unattended) uploads. Ships with a webapp test plan.	Specification	Download
HttpClient	Coming soon! HttpClient will combine the functionality of HttpPostClient and HttGetClient and support a variety of encoding types. This will reduce the number of SHEEP communication layer components to two (one client, one server), the only cost is two additional parameters.	In progress	coming soon
HttpPostClient	Save hundreds of hours of coding and testing. Runs unattended web uploads from scripts or programs. Choice of command line, program, or java method call. Ships with scripts & java code for all operating systems.	Specification	Download
HttpGetClient	Save hundreds of hours of coding and testing. Runs unattended web downloads from scripts or programs. Choice of command line, program, or java method call. Ships with scripts & java code for all operating systems.	Specification	Download

Product	Description	Documentation	Download
FolderWatch	Save fifty hours of cumbersome coding and testing. Detects new files and calls your programs. A good workmate for SHEEP components or your ERP. Ships with scripts for all operating systems.	Specification	Download
QClient	Coming Soon! This is a JMS four wheel drive that supports reading and writing to message queues on most popular message brokers (Websphere, Sonic, Apache...) A powerful companion for Business to Business and Enterprise Application Integration scenarios.	In Progress	Coming Soon
DBAggregator	Coming Soon! Useful for Enterprise data synchronization. It replicates from many sources into one. Typical use cases are Business Intelligence and feeding interstitial application (between ERPs for instance)	In Progress	Coming Soon
DBSyndicator	Coming Soon! Useful for Enterprise data synchronization. It updates many targets from a single one. Typical use cases are Enterprise Application Interfaces and ERP synchronization.	In Progress	Coming Soon
XMLValidator	Coming soon, validates any xml file against any XSD or DTD file..Know the feeling? having to validate xml in a DMZ that won't let you out to the XSD? Or you have got to validate against more than one xsd?	In Progress	Coming Soon
Emailer	Coming soon, just sends email.	in Progress	Coming Soon

Richer specification - Simpler framework
In the coming weeks the two Http clients (GET and POST) will be merged into one.
Meanwhile, encoding capabilities will be expanded. The specification will be updated accordingly.
Free License
In the coming weeks as well, SHEEP components will be made available under a Free License.
Applicability under Australian Law and International Law is being assessed.

SHEEP formulates a simple to operate Service Oriented Architecture.
SHEEP web services are easy to produce and to consume.
This is to allow the vast majority of ideas to seamlessly morph into solutions.

By easy we mean that little time and skill is required to produce and/or consume web services.
If a component operation requires skills, these skills must be limited in genre, widely available and fast to learn.
This is to allow the vast majority of human resources to achieve the vast majority of technologic tasks .

By fast we mean less than an hour to learn and less than an hour to develop.
Any learning module must last less than an hour.
Any body of work must last less than an hour.
This is to reduce inter-dependencies, facilitate teamwork, help people development.

SHEEP clients deliberately behave like web forms. HTML forms are valid SHEEP clients.

Here are the three simplest valid SHEEP clients.
GET syntax as a link: for simple standard requests.
<A href="someurl">call me</A>
GET syntax as a form: for standard request.
<form name="someform" action="someurl">
<input type="submit" name="submit"/>
</form>
POST syntax: Preferred for transactions.
<form name="someform" action="someurl" method="POST" enctype="multipart/form-data">
<input type="submit" value="submit" name="submit"/>
</form>

Now! In fourteen lines we have defined three ways to author non-elitist web services consumers.
What the services do and how the result will be used is completely irrelevant at this stage.
SHEEP's design fanatically adheres to the separation of concerns principle.
Non-Functional Requirements are the responsibility of Architects and Administrators.

There is no expectation for the format of the result; using the simplest suitable format is encouraged.

Requests are essentially web forms requests, I won’t discuss them further here.
The point here is that all web authoring tools can help in making forms and therefore SHEEP requests.

All you have to remember is that.
• Inputs must have a name.
• Different inputs may/can have the same name.
• The form itself does not even need to be served over the Internet.
• The result will be returned to your browser using a standard http response

That addresses the way to consume SHEEP web services from a web browser.
You now understand why SHEEP is the Simple Http Element Exchange Project.
All the rest is up to your existing HTML skills and your imagination.

SHEEP components are deliberately command line biased.
A single command line interface on all operating systems, this sure helps operations teams, who often have to deal with many operating systems.

Here is a scripted client.
java –jar CMHttpPostClient14.jar username="Marc" password="Personeni" url="someurl" file="order=text/xml=c:\orders\po1234.xml"

This connects to some url, authenticates as user Marc and presents the server with an order file called po1234.xml, which is identified as being in text/xml format.
The fact that the file is an order is irrelevant, it can be anything. It has not got to be only one file either, you can submit nine files and twelve values, it works just the same.

Here is another scripted client.
java –jar CMHttpGetClient14.jar url="http://ichart.finance.yahoo.com/table.csv" field="s=YHOO" field="a=00" field="b=1" field="c=2008"

This connects to Yahoo Teck Ticker and requests quotes for symbol "YHOO", since the first of January 2008.
It returns a csv file, but again the format is unimportant, it could be a google map instead.

What does that run on?
Everywhere java 1.4.2 or later is supported.

There is no need for object oriented programming with SHEEP, in fact there is hardly any programming at all. But if you want or need to code, you can. See the next section.

For coders, SHEEP is entirely based on the simplest OOP, you use components rather than derive classes.
So you don't need to be (or hire) somebody no-one can find.

Here is an example in java, it connects, authenticates and passes three values and a file.

import com.compomentis.httppostclient.HttpPostClient;
public class Demo
{
	public static void main(String[] args)
	{
    	try
        {
        	// setup the connection
            HttpPostClient client = new HttpPostClient();
            client.setUrl(“http://someurl”);
            client.setUserName(“Marc”);
            client.setPassword(“password”);
            // setup the data
            client.clearFields();
            client.setField(“text/plain”,”resume”,”pathtomyresume”);
            client.setField(“”,”firstName”,”Marc”);
            client.setField(“”,”lastName”,”Personeni”);
            client.setField(“”,”jobNumber”,”JArchSydney1234”);
            // post
            client.run();
            System.out.println(”Done”);
            }
            catch(Exception e)
            {
            	e.printStackTrace();
            }
        }
    }
     

Nothing fancy, all standard java, no special framework to train on.
Because it is so undemanding, it can actually fit everywhere.

For web developers SHEEP's component architecture makes it easy to use in java server pages.

We defined an autonomous http post server workflow and we implemented it as a java package called HttpPostServer.

Here is a generic catch-all SHEEP web service using jsp, it runs on any java application server.
It's all standard, no additional package or skill is required.
Web service results can easily be adapted to the situation.
Here the output is HTML, it could just as well be XML or anything else.

 
 <%@page contentType="text/html;charset=UTF-8"%>
 <%@page pageEncoding="UTF-8"%>
 <%@page import="com.compomentis.httppostserver.HttpPostServer" %>
 <%@page import="java.util.Enumeration" %>
 <%@page import="java.util.Vector" %>
 <%
 // This is where files will be persisted
 String outputDirectory = System.getProperty("user.home") + "/home/SheepServerData";
 // This is an upload size limit in bytes
 int MAXSIZE = 100000;
 // Here we simply ensure this is a valid POST operation (coming from a form not a link)
 String method = request.getMethod();
 if(method.equals("POST"))
 {
 try
 {
 //------------------------------------------------------------------------------------
 // Upload fields - HttpPostServer can receive fields and/or files.
 // Note: request is a standard jsp object.
 //------------------------------------------------------------------------------------
 HttpPostServer httpPostServer = new HttpPostServer(request, outputDirectory, MAXSIZE);
 httpPostServer.setLogLevel(2); // keep logging reasonably quiet
 httpPostServer.upload(); // retrieve the actual data
 //------------------------------------------------------------------------------------
 // Prepare the response
 // Set the response's Content-Type as text/plain
 // Note: To let Internet Explorer display the response in the browser window,  we also set
 // 
 Content-Disposition with the appropriate extension in filename.
 // Another Note: out is a standard jsp object.
 //------------------------------------------------------------------------------------
 out.clear();
 response.addHeader("Content-Type", "text/plain");
 response.addHeader("Content-Disposition", "inline; filename=a.txt");
 //------------------------------------------------------------------------------------
 // Fields are accessible via plain-english methods.
 //------------------------------------------------------------------------------------
 Vector fieldNames = httpPostServer.getInputFieldNames();
 Vector fieldValues = httpPostServer.getInputFieldValues();
 Vector fileNames = httpPostServer.getInputFileNames();
 Vector fileTypes = httpPostServer.getInputFileContentTypes();
 Vector fileValues = httpPostServer.getInputFilePath();
 //------------------------------------------------------------------------------------
// echo fields as name=value pairs
//------------------------------------------------------------------------------------
for(int i=0; i < fieldNames.size();i++)
 {
 out.write(fieldNames.get(i) + "=" + fieldValues.get(i));
 out.newLine();
 }
 //------------------------------------------------------------------------------------
// echo file as name=type=filename triplets (we don't echo the actual content)
//------------------------------------------------------------------------------------
for(int i=0; i < fileNames.size();i++) {
 out.write(fileNames.get(i) + "=" + fileTypes.get(i)+ "=" + fileValues.get(i));
 out.newLine();
 }
 }
 catch(Exception e) 
 {
 e.printStackTrace();
 }
 }
 %>
            

This service accepts any POST operations and reports back in HTML format. The specification let's you return other formats if you wish to. All data (field or file) is accessible just after the completion of upload().

How about authentication?
Your application server already took care of it if you told it to protect your url.

SHEEP is not aimed at a special kind of user, it rather lets anyone use it within the scope of their duties.

Let's be clear! If all the jobs are on the same person, that is fine, and SHEEP's allows it with minimum fuss.

SHEEP however is organizationally savvyer than frameworks.
Frameworks are designed by developers for developers, as if they could do as they pleased in your IT.
This freedom of work does not exist in corporations anymore. It disappeared in the wake of SOX.
Job definitions have been fragmented and roles and responsibilities clearly delimited.
As a result the "IT-guru" that writes frameworks has become nearly useless.

Frameworks are so wide that they cross organizational boundaries.
This leads to unnecessary, costly and time consuming management overhead.
Trivial pursuits require countless meetings, forming a vast base of hidden costs and quality control issues.

SHEEP components are limited in scope and do not cross organizational boundaries.
Stakeholders have a chance to perform tasks within the limits of their roles and responsibilities. It follows that, most of the time, assistance is not required.
When assistance is indeed required it is very easy to identify who should provide it.

Organizations often use multiple platforms.
For any connection scenario, Sheep allows you to use a single procedure and simple skillset, rather than a set of specific and specialized and rarely well documented procedures.
It is easier to document, audit and review.

SHEEP eases team communication, it uses a concise and well understood terminology.
Developers, operators, network engineers, business analysts, quality, project managers, architects, helpdesk... SHEEP also allows technical and procedural standardization.

SHEEP is in constant Work in Progress.
At this stage the communication and presentation layers are implemented and useful in all areas of data exchange.

Legend

Implemented complete ready to use Specification Complete implementation pending Specification in progress contributions are welcome

Implementation is 'complete' when a) Some native support is available (i.e. in a web browser or server) OR b)A SHEEP Component is available at java level 1.4.2 AND operates on all the following operating systems, Windows XP, Windows 2003 Server, Solaris 10, Mac OSX Tiger and iSeries V5R2.

	Service Band	Consumer Band
Communication Layer	HttpPostServer Specification SHEEP Component HttpGetServer Specification supported by web servers	HttpPostClient Specification SHEEP Component supported by web browsers HttpGetClient Specification SHEEP Component Supported by web browsers
Presentation Layer	ServerBound Specification url-encoded fields (GET and default POST operations) supported by web servers and web browsers multipart strings and files (POST + multipart/form-data) Supported by SHEEP HttpPostServer. ServerBorne Specification free format with content-type supported by web servers, web browsers, SHEEP HttpPostClient. RSS V2.0 Supported by SHEEP RssFeed.
Application Layer	Definition of SHEEP chaining DB Persistence FS Persistence Queuing with Message Broker Queuing without Message Broker

• SHEEP is a project developed by Compomentis Pty Ltd in Australia.
• It is a cheap interfacing method for SMEs.
• It is a Systems Integration method for the industry as well
  It is generally useful for:
  • Web services and SOA
  • EAI - A2A and B2B - It is a great delineator between ERPs.
  • eBusiness
    - For outsourced logistics, distribution or supply chain...
    - For data collation and syndication to eBusiness networks.
• It uses exclusively standard components to reduce costs.
• It reduces technology and skills requirements.
• It is organization friendly.
• IT IS FAST.
  • Fast to design
    As the only requirement on partners or service providers is to use a web URLs, a few minutes inspection of their website using a regular web browser provides all the necessary information to develop a client. Such a design roughly costs 10 to 15 dollars in technical cost terms.
  • Fast to develop
    As the components are prebuilt and their operation or coding interface is standard, developments take hours from scratch to finish.
  • Fast to run
    Mid March 08, I imported 6.2 million quotes from Yahoo TechTicker over a 512K DSL line in a little over three hours. That is about 2 million internet-to-database transactions per hour.
    All that on a A4 size AcerPower desktop with Windows XP, that I bought for 900$.
• IT IS AGILE
  No specialist skills are required, use your staff or hire regular professionals, save valuable time and tens of thousands on training collaterals (recruiter's and trainer's fees, lost employees time...)
  As it uses only standard methods and tools, you save countless hours in selecting an implementing a different "best of breed" solution with each and every partner and on each an every project.