ASIC Connect
ConnectOnline is a new offering from Australia’s corporate, markets and financial services regulator - ASIC. This serves as a window to peep into the publicly
Australia stands on top (Rank2) in Starting a business. ASIC is manages starting/registering a company in Australia.
The Searching functionality overcomes the inability for customers to conduct paid searches direct from the ASIC website. This service also enables customer to purchase products that are otherwise not available an Information Broker (eg: certificates, certified documents, and Australian Financial Services (Licensees and Representatives) extracts etc) and hence saving time visiting a service centre or mail a request for these products. Moreover, products seems to be Cheaper for Better ;)
Features include searching & buying products by:
1. Organisation Search
2. Checkname availability
3. Document Search
4. Banned and Disqualified Persons
5. Professional Registers
Purchaseable products include different types of extracts and documents for company and prof registers.
The reports can also be purchased from Information brokers
Looks like the Asic connect has more to offer for the future.
Help page
References:
Thinking of starting a business
Starting business rankings
ConnectOnline gone public!
Counterpart for New Zealand
Tuesday, April 3, 2012
Thursday, February 23, 2012
Work Manager vs Throttling in OSB
Work Manager with Proxy Service:
Work Manager configured on Proxy Service is used to limit the number of threads running a Proxy Services.
_____________________________________________________________________________________________________________________________
Work Manager with Business Service:
Work Manager configured on Proxy Service is used to limit the number of threads that process responses from the back-end system.
_____________________________________________________________________________________________________________________________
Throttling with Business Service:
Throttling configured on Business Service only limited loads (requests) to back-end services and to avoid overloading the back-end.
Throttling is used to restrict the message flow to a business service however work managers are used to prioritize service work.
Eg: The WorkManager with MaxThreadsConstraint only limits the number of threads which can be used for example to limit the number of listening threads on a queue.
If business service cannot cope with too many concurrent messages, you can edit your business service and go to the Operational Settings tab. There you can set the Throttling State to enabled and enter the number of simultaneous messages in the field Maximum Concurrency.
In case of throttling there is possibility of message loss however with work manager setup there is no such possibility.
Ref:
http://blog.xebia.com/2009/12/02/restricting-the-number-of-jms-mq-connections-made-by-the-osb/
Thursday, March 31, 2011
AusPost and DPID
Australia Post is a government owned postal authority in Australia. They operate in three core areas:
It offers delivery services, retail products, financial services (such as bill payment and banking through its retail network), logistics and fulfilment services, and direct marketing and database management services.
Australia Post's PreSort Letters Service offers discounted postage rates for customers lodging more than 300 machine-addressed articles that are barcoded and sorted. This service is the most cost effective way to send fully addressed mail. Barcoding and sorting the articles helps AusPost to more efficiently process the mail resulting in reduced costs which passed onto customer in the form of a reduced postage rate. This is commonly used by business for sending regular mails like statements, bills etc.
Benefits of PreSort Letters
Delivery Point Identifier (DPID)
The DPID is an eight-digit number that is appended to all 8.8 million delivery addresses in Australia which uniquely identifies each delivery point to which Australia Post delivers mail. It is often used as a proxy for identifying unique households and can enable discounted mailing rates when appended to a mailing list. This is barcoded which represent letters, numerals, and other human readable characters which can be deciphered by mail sorting equipment.
Appending DPID will assist your business with:
A database, called Postal Address File (PAF), is built and maintained by Australia Post. It is privacy compliant because it does not hold the names of residents but rather, just the delivery address information.
Address Matching Approval System (AMAS) is a software approval program developed by Australia Post that provides a standard by which to test and measure the quality of address matching software and its ability to append a unique Delivery Point Identifier (DPID) to each address record held within a database.
The barcode format adopted by Australia Post is called the 4-State barcode. The name is derived from the fact that the bars can only be placed in one of four positions - Tracker on its own, Tracker with Ascender, Tracker with Descender, and Tracker with Ascender and Descender.
When an address is validated, a BSP (Barcode Sort Plan) number, ranging from 1 to 54, is assigned to each postcode. To benefit from Barcoded PreSort mail discounts, mail must be sorted by the BSP number.
- Letters and associated services;
- Retail merchandise and agency services; and
- Parcels and logistics.
It offers delivery services, retail products, financial services (such as bill payment and banking through its retail network), logistics and fulfilment services, and direct marketing and database management services.
Australia Post's PreSort Letters Service offers discounted postage rates for customers lodging more than 300 machine-addressed articles that are barcoded and sorted. This service is the most cost effective way to send fully addressed mail. Barcoding and sorting the articles helps AusPost to more efficiently process the mail resulting in reduced costs which passed onto customer in the form of a reduced postage rate. This is commonly used by business for sending regular mails like statements, bills etc.
Benefits of PreSort Letters
- save money with our discounted postage rates.
- receive further discounts when choosing off peak services.
Delivery Point Identifier (DPID)
The DPID is an eight-digit number that is appended to all 8.8 million delivery addresses in Australia which uniquely identifies each delivery point to which Australia Post delivers mail. It is often used as a proxy for identifying unique households and can enable discounted mailing rates when appended to a mailing list. This is barcoded which represent letters, numerals, and other human readable characters which can be deciphered by mail sorting equipment.
Appending DPID will assist your business with:
- Reducing dead mail costs
- Achieving bulk mail discounts
- DPID can help identify invalid or duplicate addresses.
A database, called Postal Address File (PAF), is built and maintained by Australia Post. It is privacy compliant because it does not hold the names of residents but rather, just the delivery address information.
Address Matching Approval System (AMAS) is a software approval program developed by Australia Post that provides a standard by which to test and measure the quality of address matching software and its ability to append a unique Delivery Point Identifier (DPID) to each address record held within a database.
The barcode format adopted by Australia Post is called the 4-State barcode. The name is derived from the fact that the bars can only be placed in one of four positions - Tracker on its own, Tracker with Ascender, Tracker with Descender, and Tracker with Ascender and Descender.
When an address is validated, a BSP (Barcode Sort Plan) number, ranging from 1 to 54, is assigned to each postcode. To benefit from Barcoded PreSort mail discounts, mail must be sorted by the BSP number.
Sunday, December 12, 2010
Contactless Credit Cards and Electronic Pickpocketing
Recent development in the Credit Card market is the contact-less cards - just wave at the terminal to pay.
Providers include
Visa: Visa Contactless, PayWave
MasterCard: PayPass
American Express: Express Pay
In Australia, major banks like Commonwealth Bank, ANZ, Macquarie Bank & NAB are offering.
Limit: Visa PayWave - AU$100 and Mastercard PayPass - AU$35
Benefits:
How Does a Contactless Credit Card Work?
The cards contain RFID chips and the communication between credit card and terminal are completed through radio waves and the data transmission encrypted. It will work as long as the card is 4 centimetres or less from the terminal. No more swiping or insertion into card reader; simply tap and go.
Risks & explanations
These chips encode basic information (e.g., account numbers, expiration dates) that can be picked up by point-of-sale RFID readers, eliminating the need for cards to be physically handled or swiped. One possible drawback to this technology is that unauthorized persons might use RFID readers of their own to surreptitiously glean that same information using a card reader and a netbook computer to engage in card "skimming".
Luckily, The data streams emitted by contactless cards don't include such information as PINs and CVV security codes or in newer cards, customer name. Without those pieces of information a card skimmer should not be able to utilize the stolen card numbers to print up counterfeit cards or engage in Card Not Present transactions.
Payment companies claim that the process of making purchases with the cards involves verification procedures based on powerful encryption that make each transaction unique. Most cards transmit a dummy number that does not match the number embossed on the card and that number can be used only in connection with the verification token, that is encrypted before being sent.
Alternately a stainless steel wallet saves the card ;)
They are already popular in transport world:
In2Pay Contactless Payment - even iPhone App
Visa and DeviceFidelity collaborated to combine Visa’s contactless payment technology Visa payWave with the In2Pay technology. The microSD memory slot of the iPhone enables a mobile contactless payment device. This applies to any mobile phone.
The In2Pay solution transforms any mobile phone with a microSD memory slot into a mobile contactless transaction device, offering a full-featured user interface that supports multiple mobile operating systems. The In2Pay microSD v2 is Trusted Service Manager (TSM) ready, allowing TSM client software on mobile devices to interact with the In2Pay Secure Element through a new Java based Application Programming Interface (In2Pay API). The patented TSM ready architecture of the In2Pay v2 allows TSM providers to support the In2Pay solution without modifying the TSM server designed for embedded or SIM based NFC solutions. With In2Pay v2, DeviceFidelity builds on the plug-and-play features of previous versions to meet the growing market demand for a mobile contactless solution that can interact with wallet solutions of established TSM vendors and can be issued through multiple delivery channels.
Misc:
Open Project Directory
RFID - Radio Frequency Identification
CVV - Card Verification Value (normally 3 digit security code behind the card)
Providers include
Visa: Visa Contactless, PayWave
MasterCard: PayPass
American Express: Express Pay
In Australia, major banks like Commonwealth Bank, ANZ, Macquarie Bank & NAB are offering.
Limit: Visa PayWave - AU$100 and Mastercard PayPass - AU$35
Benefits:
- Greater convenience - no need to carry cash in hand
- Greater speed to pay
- Innovative experience
- Greater security – while purchasing goods, your card will never leave your hands. This reduces the risk that your card details may be copied or compromised in any way.
How Does a Contactless Credit Card Work?
The cards contain RFID chips and the communication between credit card and terminal are completed through radio waves and the data transmission encrypted. It will work as long as the card is 4 centimetres or less from the terminal. No more swiping or insertion into card reader; simply tap and go.
Risks & explanations
These chips encode basic information (e.g., account numbers, expiration dates) that can be picked up by point-of-sale RFID readers, eliminating the need for cards to be physically handled or swiped. One possible drawback to this technology is that unauthorized persons might use RFID readers of their own to surreptitiously glean that same information using a card reader and a netbook computer to engage in card "skimming".
Luckily, The data streams emitted by contactless cards don't include such information as PINs and CVV security codes or in newer cards, customer name. Without those pieces of information a card skimmer should not be able to utilize the stolen card numbers to print up counterfeit cards or engage in Card Not Present transactions.
Payment companies claim that the process of making purchases with the cards involves verification procedures based on powerful encryption that make each transaction unique. Most cards transmit a dummy number that does not match the number embossed on the card and that number can be used only in connection with the verification token, that is encrypted before being sent.
Alternately a stainless steel wallet saves the card ;)
They are already popular in transport world:
- Octopus card in Hong Kong (1st ever)
- Oyster card in London
- Navigo pass in Paris
- Suica in Tokyo
- SL Access card in Stockholm
- Clipper card in San Francisco
- Delhi Metro rail
In2Pay Contactless Payment - even iPhone App
Visa and DeviceFidelity collaborated to combine Visa’s contactless payment technology Visa payWave with the In2Pay technology. The microSD memory slot of the iPhone enables a mobile contactless payment device. This applies to any mobile phone.
The In2Pay solution transforms any mobile phone with a microSD memory slot into a mobile contactless transaction device, offering a full-featured user interface that supports multiple mobile operating systems. The In2Pay microSD v2 is Trusted Service Manager (TSM) ready, allowing TSM client software on mobile devices to interact with the In2Pay Secure Element through a new Java based Application Programming Interface (In2Pay API). The patented TSM ready architecture of the In2Pay v2 allows TSM providers to support the In2Pay solution without modifying the TSM server designed for embedded or SIM based NFC solutions. With In2Pay v2, DeviceFidelity builds on the plug-and-play features of previous versions to meet the growing market demand for a mobile contactless solution that can interact with wallet solutions of established TSM vendors and can be issued through multiple delivery channels.
Misc:
Open Project Directory
RFID - Radio Frequency Identification
CVV - Card Verification Value (normally 3 digit security code behind the card)
Tuesday, November 23, 2010
When to use OSB & BPEL?
Use OSB for:
Use BPEL for:
- Endpoint routing (providing location transparency) so that we do not care about the physical location of the endpoint.
- Endpoint abstraction (interface transparency) so that we do not care about the exact data formats required by the endpoint because the OSB will take care of transformations.
- Load balancing so that we do not care about which of multiple service implementations will actually service a request.
- Throttling so that we do not care about how use of services is restricted.
- Enrichment so that we do not care about how additional data is provided to the request to match the expected request and response formats.
- Simple synchronous composition so that we do not care if our abstract service call is actually made up of two or more physical service calls.
- Protocol conversion so that we do not care what physical transports are being used.
- Sync/async abstraction so that we can treat services as fire and forget or query response according to the needs of the client.
Use BPEL for:
- Complex composition of parallel flows that involve more than a couple of services.
- Long running compositions that may run for minutes, hours or days.
- Asynchronous compositions that require correlation of requests and responses.
- Process abstraction that enables us to track processes and their interactions with multiple services.
- Human workflow
Related blog topics:
what is EAI?
EAI
1. A centralized broker that handles security, access, and communication. This can be accomplished through integration servers (like the School Interoperability Framework (SIF) Zone Integration Servers) or through similar software like the Enterprise service bus (ESB) model that acts as a SOAP-oriented services manager.
2. An independent data model based on a standard data structure, also known as a Canonical data model. It appears that XML and the use of XML style sheets has become the de facto and in some cases de jure standard for this uniform business language.
3. A connector, or agent model where each vendor, application, or interface can build a single component that can speak natively to that application and communicate with the centralized broker.
4. A system model that defines the APIs, data flow and rules of engagement to the system such that components can be built to interface with it in a standardized way. This aids Orchestration
Advantages
SOA is a loosely coupled solution to replace EAI (didn't kill EAI though).
1. A centralized broker that handles security, access, and communication. This can be accomplished through integration servers (like the School Interoperability Framework (SIF) Zone Integration Servers) or through similar software like the Enterprise service bus (ESB) model that acts as a SOAP-oriented services manager.
2. An independent data model based on a standard data structure, also known as a Canonical data model. It appears that XML and the use of XML style sheets has become the de facto and in some cases de jure standard for this uniform business language.
3. A connector, or agent model where each vendor, application, or interface can build a single component that can speak natively to that application and communicate with the centralized broker.
4. A system model that defines the APIs, data flow and rules of engagement to the system such that components can be built to interface with it in a standardized way. This aids Orchestration
Advantages
- Real time information access among systems
- Streamlines business processes and helps raise organizational efficiency
- Maintains information integrity across multiple systems
- Ease of development and maintenance
- High initial development costs, especially for small and mid-sized businesses (SMBs)
- Require a fair amount of up front business design, which many managers are not able to envision or not willing to invest in.
SOA is a loosely coupled solution to replace EAI (didn't kill EAI though).
Canonical Data Model & the pattern
Canonical Data Model
Canonical implies => simplest form possible based on a standard, common view within a given context. Canonical Model is a design pattern used to communicate between different data formats in Enterprise Application Integration (EAI) - it is intended to reduce costs and standardize on agreed data definitions associated with integrating business systems. Canonical Data Model - an enterprise design pattern which provides common data naming, definition and values within a generalized data framework.
A typical migration from point-to-point (P2P) interfacing to message based integration (MOM) begins with a decision on the middleware to be used to transport messages between endpoints. Often this decision results in the adoption of an Enterprise Service Bus (ESB) or Enterprise Application Integration (EAI) solution. Most organizations also adopt a set of standards for message structure and content (message payload). The desire for consistent message payload results in the construction of an enterprise/business domain Canonical Model or adoption of an XML message standard used as the basis for message objects.
The goal of the Canonical Model is to provide a dictionary of reusable common objects and definitions at an enterprise or business domain level to enhance system interoperability. "A Canonical Data Model allows developers and business users to discuss the integration solution in terms of the company's business domain, not a specific package implementation. For example, packaged applications may represent the common concept of a customer in many different internal formats, such as 'account', 'payer', and 'contact'. Defining a Canonical Data Model is often the first step to resolving cases of semantic dissonance between applications." Enterprise integration models provide a foundation for a decoupled, consistent, reusable integration methodology which can be implemented using messaging supported by middleware products. Message payloads (business data content) in the form of XML schema are built from the common model objects thus providing the desired consistency and re-usability while ensuring data integrity.
Done as "Data format and transformation" in two steps: the adapter converts information from the application's format to the bus's common format. Then, semantic transformations are applied on this (Eg: converting zip codes to city names, splitting/merging objects from one application into objects in the other applications, and so on). Eg: When integrating 2 disperate systems (say: Mainframe MF & a Siebel), the canonical model could be common language, each one translates to for speaking to eachother.
Canonical Schema Pattern
In order for a service consumer to send data (related to a particular business entity e.g. a purchase order), it needs to know the structure of the data i.e. the data model. The interaction between services often requires exchanging business documents often complying to certain stds eg: XML schema document (xsd). Once the service consumer knows the required data model, it can structure the data accordingly. However, under some conditions it may be possible that the service consumer already possesses the required data, which relates to a particular business document, but the data does not conform to the data model as specified by the service provider. This disparity among the data models results in the requirement of data model transformation (so that the message is transformed into the required structure as dictated by the service provider). This runtime data model transformation adds processing overhead and complicates the design of service compositions.
In order to avoid the need for data model transformation, the Canonical Schema pattern dictates the use of standardized data models for those business documents that are commonly processed by the services in a service inventory. Here, a Standardized Service Contract design principle advocates that the service contracts be based on standardized data models. This is achieved by performing an analysis of the service inventory blueprint, in order to find out the commonly occurring business documents that are exchanged between services. These business documents are then modeled in a standardized manner. For example, in case of web services, the business documents are modeled as XML schemas. Once a standardized data representation layer exists in a service inventory, different service contracts can make use of the same data models if they need to exchange the same business documents. This eliminates the need for any data model transformation and reduces the processing overhead associated with the data model transformation. Another way is to reuse the commonly used elements composed as complex types but involves repeated usage eg: Between Checkout Service & Payment Service, LineItems are repeatable and can be reused.
Canonical implies => simplest form possible based on a standard, common view within a given context. Canonical Model is a design pattern used to communicate between different data formats in Enterprise Application Integration (EAI) - it is intended to reduce costs and standardize on agreed data definitions associated with integrating business systems. Canonical Data Model - an enterprise design pattern which provides common data naming, definition and values within a generalized data framework.
A typical migration from point-to-point (P2P) interfacing to message based integration (MOM) begins with a decision on the middleware to be used to transport messages between endpoints. Often this decision results in the adoption of an Enterprise Service Bus (ESB) or Enterprise Application Integration (EAI) solution. Most organizations also adopt a set of standards for message structure and content (message payload). The desire for consistent message payload results in the construction of an enterprise/business domain Canonical Model or adoption of an XML message standard used as the basis for message objects.
The goal of the Canonical Model is to provide a dictionary of reusable common objects and definitions at an enterprise or business domain level to enhance system interoperability. "A Canonical Data Model allows developers and business users to discuss the integration solution in terms of the company's business domain, not a specific package implementation. For example, packaged applications may represent the common concept of a customer in many different internal formats, such as 'account', 'payer', and 'contact'. Defining a Canonical Data Model is often the first step to resolving cases of semantic dissonance between applications." Enterprise integration models provide a foundation for a decoupled, consistent, reusable integration methodology which can be implemented using messaging supported by middleware products. Message payloads (business data content) in the form of XML schema are built from the common model objects thus providing the desired consistency and re-usability while ensuring data integrity.
Done as "Data format and transformation" in two steps: the adapter converts information from the application's format to the bus's common format. Then, semantic transformations are applied on this (Eg: converting zip codes to city names, splitting/merging objects from one application into objects in the other applications, and so on). Eg: When integrating 2 disperate systems (say: Mainframe MF & a Siebel), the canonical model could be common language, each one translates to for speaking to eachother.
Canonical Schema Pattern
In order for a service consumer to send data (related to a particular business entity e.g. a purchase order), it needs to know the structure of the data i.e. the data model. The interaction between services often requires exchanging business documents often complying to certain stds eg: XML schema document (xsd). Once the service consumer knows the required data model, it can structure the data accordingly. However, under some conditions it may be possible that the service consumer already possesses the required data, which relates to a particular business document, but the data does not conform to the data model as specified by the service provider. This disparity among the data models results in the requirement of data model transformation (so that the message is transformed into the required structure as dictated by the service provider). This runtime data model transformation adds processing overhead and complicates the design of service compositions.
In order to avoid the need for data model transformation, the Canonical Schema pattern dictates the use of standardized data models for those business documents that are commonly processed by the services in a service inventory. Here, a Standardized Service Contract design principle advocates that the service contracts be based on standardized data models. This is achieved by performing an analysis of the service inventory blueprint, in order to find out the commonly occurring business documents that are exchanged between services. These business documents are then modeled in a standardized manner. For example, in case of web services, the business documents are modeled as XML schemas. Once a standardized data representation layer exists in a service inventory, different service contracts can make use of the same data models if they need to exchange the same business documents. This eliminates the need for any data model transformation and reduces the processing overhead associated with the data model transformation. Another way is to reuse the commonly used elements composed as complex types but involves repeated usage eg: Between Checkout Service & Payment Service, LineItems are repeatable and can be reused.
Service A is using a different data model as compared to Service B for the same business document. When messages are exchanged, runtime data model transformation needs to be performed.
Both services are using the same data model for representing a particular business document. AS a result, no data model transformation is required when messages are exchanged.
Subscribe to:
Posts (Atom)