Related to Greg McCarroll's post about a getting a glossary together... Glossary Background:
Different people have different thoughts related to what these terms mean which causes semantic arguments. A common glossary will help mitigate this issue. As much as possible I have tried to draw upon the definitions from a "Java" perspective first because part of the P5EE initiative is built around bridging Perl Enterprise APIs to Java Enterprise APIs, "where applicable". === Enterprise - (From techtarget.com definition that Sun links to) In the computer industry, an enterprise is an organization that uses computers. A word was needed that would encompass corporations, small businesses, non-profit institutions, government bodies, and possibly other kinds of organizations. The term enterprise seemed to do the job. In practice, the term is applied much more often to larger organizations than smaller ones. Editors Addition: In the case of J2EE, enterprises also include logical organization units formed out of multiple entities collaborating together and not necessarily geographically colocated. === J2EE - The short definition is the Java 2 Platform, Enterprise Edition. Specifically, it encapsulates the standard SDK and adds the following elements: * The J2EE Application Programming Model is the standard programming model used to facilitate the development of multi-tier, thin client applications. * The J2EE Platform includes necessary policies and APIs such as the Java servlets and Java Message Service (JMS). * The J2EE Compatibility Test Suite ensures that J2EE products are compatible with the platform standards. * The J2EE Reference Implementation explains J2EE capabilities and provides its operational definition. The technologies that J2EE encapsulates is listed at http://java.sun.com/products/OV_enterpriseProduct.html * Enterprise JavaBeans Architecture * JavaServer Pages * Java Serlvet * J2EE Connector * Java Naming and Directory Interface (JNDI) * Java Interface Definition Language (IDL) * JDBC * Java Message Service (JMS) * Java Transaction API (JTA) * Java Transaction Service (JTS) * JavaMail * RMI-IIOP === API - Application Programmer's Interface. For an object-oriented language, this entails the methods and objects that may be called to accomplish a task. === Frameworks - A framework builds on top of an API but recognizes that in order for certain APIs to be useful, much of the programming must be left "undone" because the programming for particular domains are too specific to the problem domain. Therefore, rather than a pre-completed API, a framework leaves skeletons open to be fleshed out by coders in such a way that when these skeleton interfaces are fleshed out, then they will plug straight into an existing API. === Generic (or Horizontal) Framework - A generic framework consists of a framework built for many domains. Where the "skeleton interfaces" are left uncompleted, the developer would code their own concrete components to plug into the framework in order to give the framework life. An example "generic framework" is a combination of the Java Servlet API *and* a given Servlet Container. The API as discussed earlier is a self-contained programming interface, but in order to be useful, a servlet container must exist. Unfortunately, servlet containers typically do not provide pre-written servlets and therefore this piece must be written. This is in contrast to a pure API such as JavaMail which when coupled with any application does something particularly and immediately useful such as sending email. Examples in the open source world include Zope (Python)'s framework for Content Management, AxKit in mod_perl for managing site content in XML, Mason (similar roots to AxKit but not XML specific), eXtropia and OpenInteract's Perl web application frameworks, etc. === Domain (or Vertical) Framework - A domain specific framework is a framework that is useful for just a single or limited set of problem domains. This may include e-Commerce, Banking, Life Sciences, etc. An example of a vertical framework is IBM's San Francisco project. http://www-4.ibm.com/software/ad/sanfrancisco/ which is a framework built on top of J2EE to allow businesses to produce e-Business applications fairly quickly. === Services - A service is an API that is exposed to the public (can be restricted by password or domain though) to allow arbitrary applications access to get data or perform an operation without strict compile time checking or reliance on that one service. Criteria for a service includes a server, an exposes API, and a public protocol that can expose the API in a reasonably accurate fashion. An example of a service is SOAP (Simple Object Access Protocol). === Web Services - A Web Service is a service where the public API is exposed over the Internet and more precisely or accurately, using HTTP/HTTPS. A web service a particularly powerful model versus simply exposing CORBA or RMI over the internet because web services automatically benefit from authentication in a web server and other web server features. In addition, firewalls are usually configured to be HTTP-friendly allowing web services to be more ubiquitous than services that are tied to more closed protocols. === Component - (Definition from CCA Forum) - A component is a software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities. A component has a clearly defined interface and conforms to a prescribed behavior common to all components within an architecture. Multiple components may be composed to build other components. Editors Note: this is curiously similar to what many programmer's mean when they talk about "Objects". The difference is that an object may be written to work within a single application whereas a component or set of components is usually meant to be exposed for use in many different applications and installed in a variety of environments. For example, a single object's interface may be completely PRIVATE to that application, but a component by definition must have SOME methods exposed with a PUBLIC interface allowing others to interact with it. A component may be accessed through a programming/compile-time interface, but if a component is exposed via a remote API such as Soap, then it will become a "Service". === Bean - A reusable software component that can be visually manipulated in builder tools (or via the command-line). A bean specifically can store it's own state and it's own definition and it's properties are exposed through a common convention or API. The most popular example of beans are "Java Beans". Beans were considered revolutionary in Java because they allowed "configuration" for an application to be stored as the "state" of the bean without recompiling the bean. Previously, to change an object, you had to go to the Java source code for the class and change the code to reflect new defaults and then recompile the object. By allowing the definition of a class, and the state of the instantiated class (object) to be stored side by side, it allowed a tool to go in and change the persistent state of the object for future use (ie configuration). Perl can benefit from the concept of beans, but traditionally if you change a variable in a Perl program, it will be reflected immediately without a recompile to an intermediate class file, thus beans have not received the same level of recognition in Perl due to the language design of Perl itself (see Perl Beans definition below). === Perl Beans - This would be a Perl object that conforms to the definition of a bean. Currently there is no "bean" convention in Perl. Perl is a loosely typed scripting language, so the concept of a bean is less immediately obvious in Perl than in Java. However, beans do allow the following: * Integration with IDEs for building applications/tools * Integration with GUIs for deployment without requiring a separate XML descriptor (eg Deployment of Perl Beans within a transaction server or as a SOAP Service) XML is currently another means of describing the state of an object. For example, nowadays Java JSP tag libraries come with an XML descriptor (TLD tag library descriptor) describing the properties that a given tag will expose. However, even with an XML descriptor, the bean "convention" in Java still helps. For example, one bean convention is that a property has a "get" and optional "set" method. So if the property is called "color" then the bean must have a method called getColor and setColor. Boolean properties may optionally be prefixed with "is" instead of "get" such as isCool might describe the cool property of a language operator. Thus, in an XML file describing a tag in JSP, the properties would be listed. And then the servlet container can optionally take the propery list and make sure the requisite get and set methods exist in the tag class definition following the bean convention exist. === Anyway this is pretty much it. If there are more definitions or better definitions to use, please feel free to step forward. __________________________________________________ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
